[BusyBox] kernel 2.6 detection bug in loop.c

[Rob Landley]

On Monday 16 August 2004 08:53, Aurelien Jacobs wrote:
> On 8/16/2004, "Aurelien Jacobs" <aurel at gnuage.org> wrote:
> >>> I don't know when __kernel_old_dev_t is needed, but with a 2.6.7
> >>> or a 2.6.8 this is __kernel_dev_t wich is needed.
> >>
> >>It isn't.  It was hack for early Maszur headers for around kernel 2.6.2
> >> and earlier.  It patches around a problem that was fixed long ago.
> >
> >I've investigated a bit more to understand where does the error come
> >from.
> >It revealed that when compiling with uClibc 0.9.26 the file
> >bits/kernel_types.h is silently included when compiling loop.c and this
> >header also define __ARCH_I386_POSIX_TYPES_H, so after this, including
> >asm/posix_types.h has no effect at all.
> >bits/kernel_types.h only define __kernel_dev_t. It don't define
> >__kernel_old_dev_t.

I'm fairly certain it also broke with glibc, but this was at least six months 
ago and I don't have the right test environment set up anymore...

> Sorry about all this, but the bug was in uClibc 0.9.26 !
> It's now corrected in uClibc cvs by:
> typedef __kernel_dev_t  __kernel_old_dev_t;
> in kernel_types.h. Thanks !

Actually, looking closer at it, in 2.6 kernel_dev_t switched from an unsigned 
short to __u32, to support larger device types.  (This is on intel.  Parisc 
was already using an int, and so on...)  So the above still isn't happy.  
Looking at the code, the only reason it worked in my test is I never tried to 
feed it a nonzero lo_offset or encryption type.  I just compiled and 
associated loopback stuff, which doesn't care that the fields are skewed, the 
FD is an argument to the ioctl...  And apparently I never noticed that the 
name would be blank...

That said, the #ifdef forest we've got at the top of that file is simply icky.  
Why on _earth_ do we have version specific hacks to try to figure out which 
external dependencies may or may not be broken?  I'm not sure fixing uclibc 
is the answer if the code will still contain icky #ifdefs that care way too 
much about other things' internals.  (There's no way to do an #ifdef for a 
typedef, is there?)

What we _really_ want to do is use loop_info64 where appropriate.  Lemme 
ponder this.

> >I've made a new patch against latest CVS. It is based on Rob Landley idea
> >and should work with any kernel and libc version.
>
> Sorry about this patch. It was plain wrong anyway !
> (was using #ifdef on types defined with typdef ;-)

It would be so nice if there WAS some way to do that.  The whole problem would 
be solved immediately...

My fix turns out to be wrong anyway.  Frustrating.  Icky.  Evil code.  Let me 
think about it some more...

> Aurel

Rob
-- 
www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas.  (I'm the con chair.)