mm and Oops
After sending util-linux out, I booted a kernel that had kdev_t a pointer type, to see whether that still works.
And all (minus md/lvm/nfs that didnt compile) was fine except that kswapd produced an oops. Investigation shows that it was caused by the combination of what <linux/swap.h> calls "Ugly ugly ugly HACK" and what <linux/kdev_t.h> judges with "yuk".
So, maybe we must remove one or both of these sore spots. The second one is the use of a special constant B_FREE as device value to indicate that the buffer is free. I'll look at this tomorrow but perhaps someone knows:
must the constant B_FREE (used only in fs/buffer.c) be nonzero? If so, then we probably need a bitfield to indicate "free". Otherwise we can use 0 ("no device") as value.
Andries
Quoted 3 lines · Andries
After sending util-linux out, I booted a kernel that had
kdev_ta pointer type, to see whether that still works.
And all (minus md/lvm/nfs that didnt compile)...
Yes, LVM totally abuses kdev_t (assumes = dev_t in user space). Changing kdev_t should force this to be cleaned up.
Quoted 6 lines
The second one is the use of a special constant
B_FREEas device value to indicate that the buffer is free. I'll look at this tomorrow but perhaps someone knows:
must the constantB_FREE(used only infs/buffer.c) be nonzero? If so, then we probably need a bitfield to indicate "free". Otherwise we can use 0 ("no device") as value.
Isn't a device = 0 used for NFS root?
Cheers, Andreas
Signature · 3 lines
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert