If you want to make a kernel change, you are going to have to champion its
cause. If you don't make an effort, no one else will either.
FYI: I never saw said patches, but only browse messages that directly
affect or interest me.
> PS1 - I do not read the linux-kernel mailing list, and the newsgroup
> is mostly dead. Cc to me if you want me to read a reaction.
This doesn't help you gain support for your changes. A public forum
like the mailing list is best getting feeback. Yes, you have to slog
through a lot of stuff that doesn't concern you, but that is what it
takes.
> PS2 - A few days ago somebody reminded me again of my promise to make
> kdev_t a pointer to a device driver struct, and to handle the
> transition to large device numbers. Well, I write this from
> a kernel where kdev_t is a pointer and device numbers have
> 32 bits, but Linus does not consider this change urgent,
> so as far as I am concerned this matter will sleep for half a year or so.
Then _you_ have to convince Linus and everyone it is urgent, or an
otherwise useful patch that deserves to be put in the kernel distribution.
Linus and the others are very reasonable IMHO. Usually when something
gets put off, it is for a very good reason. Example: I've still not
heard anything about there being a final statement on kdev_t (format, etc.)
Maybe I missed it, but maybe there isn't agreement yet.
> Edited patch below - line numbers may differ.
>
> --- ../../../../linux-2.0.30/linux/fs/isofs/inode.c Sat Aug 17 20:19:28 1996
You'd get a lot more support if you hacked the experimental (2.1.*) kernels.
Nothing but fatal flaws seem to get corrected in production (2.0.*) kernels.
Happy hacking.
-- Andrew E. Mileski mailto:aem@netcom.ca Linux Plug-and-Play Hardware Support http://www.redhat.com/linux-info/pnp/ XFree86 Matrox Team http://www.bf.rmit.edu.au/~ajv/xf86-matrox.html