[pisa-src] Re: r1152 - in trunk/community-operator: Makefile.am co_client.c co_client.cfg co_common_packets.h co_server.c hipl.c hipl.h
- From: Thomas Jansen <mithi@xxxxxxxxx>
- To: pisa-src@xxxxxxxxxxxxx
- Date: Thu, 15 Oct 2009 13:22:46 +0200
On Thu, Oct 15, 2009 at 01:10:46PM +0200, Diego Biurrun wrote:
> > Not correct indeed, but I didn't have a nice solution for that problem when
> > I
> > talked to Jan yesterday. Still this needs to be resolved, before we can
> > continue to create a better world (i.e. have a single makefile).
> >
> > Perhaps the C file could be added to the sources of the project directly?
> > Not
> > by copying, but by referencing the out of tree source file in
> > @PISA_HIPL_SRCDIR@/firewall.
>
> How large is the function? We could copy it as well...
Then you have duplicate code and even though it is in two different projects,
you'd still have to keep it in sync manually.
> > I know the rule in doc/HACKING states "Use
> > 4 spaces as TAB in userspace and 8 spaces ad TAB in kernelspace!" and for me
> > that translates to "set your editor to a tab width of 4 or 8". I admit
> > though,
> > that it is easy to misunderstand the way that the rule is written.
>
> I understood it to mean "use 4 space indentation in userspace, tabs in
> kernelspace".
I spoke to Tobi earlier, who confirmed that the intention is to use tabs
everywhere, but set a different tab width. The way it was expressed in
docs/HACKING is not unambigous though. Tracking the count of spaces isn't
trivial, a missing or unintended tab is easier to spot. Space increases
the size of the source code unnecessarily in my opinion.
--
Thomas Jansen, "Mithi" --- mithi@xxxxxxxxx
GPG 9D5C682B, feel free to sign or encrypt your mail
Other related posts:
