lkml.org 
[lkml]   [1997]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: fix for iso9660 fs
Date
> Since that is a kernel bug, not a mount bug, let me submit
> a patch again. (The first time was a nice and beautiful patch
> doing the option parsing for all file systems in a uniform way,
> using one single routine. No reaction. The second one was a patch
> correcting all of the option parsing for iso9660. No reaction.
> This is the third time, with a patch correcting only this minor point.)

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

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2011 Jasper Spaans