[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [PATCH] hdparm 6.6  1/2
From:       Tito <farmatito () tiscali ! it>
Date:       2006-04-30 8:52:00
Message-ID: 200604301052.00326.farmatito () tiscali ! it
[Download RAW message or body]

On Saturday 29 April 2006 22:35, you wrote:

> Erik believed that #including kernel headers was always wrong.  Unfortunately, 
> loop.c was a clear a counter-example.  Cutting and pasting a recent rant I 
> wrote on linux-kernel:
> 
> > Busybox's losetup code wants linux/loop.c because nothing else #defines that 
> > structure, and cut and pasting it into a local header file is incredibly 
> > painful because portions of that structure vary by architecture, namely 
> > __kernel_dev_t has different sizes on alpha, arm, x86... meaning we have to 
> > #include linux/posix_types.h unless we want to hard wire into our code 
> > #ifdefs that type for every architecture out there.  This is _bypassing_ the 
> > fact that we already #include linux/version.h and check if we're building on 
> > 2.6, and if so just use the 64 bit structure instead to avoid the whole 
> > _old_kernel_dev_t rename entirely.
> > 
> > We spent _two years_ trying to figure out a clean way to do all that.  There 
> > isn't one.
> > 
> > And no, util-linux isn't doing it cleanly either.  They just hide the
> > ugliness by nesting #include files.  mount/loop.h #includes my_dev_t.h which
> > #includes <linux/posix_types.h> and <linux/version.h> just like we do,
> > because THERE IS NO ALTERNATIVE.
> 
> I do believe that we should never directly include kernel headers when there's 
> a better way to do it, but I also believe that block copying the contents of 
> the kernel headers into our program does not qualify as a better way to do 
> it.

Ok, maybe we should add this to programming.html.

> I'm curious about the space savings, since defining smaller structs shouldn't 
> make a major difference to the binary size.  (Declaring smaller globals 
> would.)  Do you know what the space savings is from?  I applied a portion of 
> the patch towards the end that was unrelated to the header move...

If you really care about this, i can investigate it (maybe it was a side effect
of some other unrelated change?!).

BTW: i've posted one more cleanup patch (06) that removes obsolete
and dead code from hdparm syncing it with the latest version.
If you have some time could you take a look at it.

Ciao,
Tito 
> Rob
> --
> Never bet against the cheap plastic solution.
> 
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]