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

List:       busybox
Subject:    Re: [PATCH] hdparm 6.6 1/2
From:       Rob Landley <rob () landley ! net>
Date:       2006-04-29 15:25:41
Message-ID: 200604291125.42044.rob () landley ! net
[Download RAW message or body]

On Friday 28 April 2006 8:18 pm, Jason Schoon wrote:
> > It already won't work on any environment where those headers are unlikely
> > to
> > be there, would we prefer that it didn't work at build time or it didn't
> > work
> > at runtime?
>
> It doesn't make it less linux-specific, but it does make it less kernel
> version specific.  In general, I think it isn't a bad idea to do this in
> cases where it is some define that is not likely to be changing.  If it is
> instead some function that may change based on the target kernel, than
> sticking with the linux headers is probably less work.

I'm confused: how does it make it less kernel version specific?  At build 
time, sure, but then you get something that doesn't work.  If the #define 
doesn't change then it should reliably be in the headers, no?  And if it does 
change based on the target kernel, then the headers tell you what the target 
kernel can do.

There's a move underway to finally give us sane header exports from the 2.6 
kernel:  http://www.ussg.iu.edu/hypermail/linux/kernel/0604.2/1830.html

Which looks like it'll go in around 2.6.18.

I like the size reduction, and just committed the 1/3 or so of the headers 
cleanup patch I'm comfortable with.  (It built, can't guarantee much beyond 
that at the moment.)

I don't see how putting #ifdefs around structure defines (not declarations, 
but type definitions) is supposed to save space.

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]