>
> Yes, mine has. I'm looking forward to your positive contributions to
> drivers/sound.
How does one go about doing this? I used to do a lot of kernel-hacking
back in the early '80s, and have provided the odd patch here and there,
but I don't do politics well and developed the sense that Linux was sort
of divided up into fiefdoms and that I had little chance of getting stuff
into the kernel. Combine that with natural sloth and aversion to
flame-wars and one has a formidable barrier. I have considered a rewrite
of low-level physical memory management, something I partially did back in
my ancient v7/sys3/sysv kernel, but that is a lot of work to do on
speculation. I ran up against Linux mm when porting/rewriting the driver
for the Matrox Meteor framegrabber back in '96 (I made it as a separate
module, so it is not in the source tree [really doesn't need to be]); I
had to use Matt's bigphysarea patch in order to get contiguous
multi-megabyte slabs of memory, and I rooted around the mm code a lot
before resorting to this to confirm that it was not set up to support
this, and was in general somewhat arcane. I haven't looked recently;
perhaps all that has changed.
I've offered to touch up the readme.modules (several times) but have
gotten no response. My suggestions about the module stuff would either
have to be backwards-compatible or would require touch-ups to every
modular driver; in either case I would be hesitant to wade into it without
a go-ahead from those who own those areas of code. I am willing, as I
said, to at least do some research on it if the Linux equivalent of the
group managers offer me some political coverage or whatever it is one is
supposed to have to do this, which I make no pretense of understanding.
>
> Regards,
>
> Michael
>
--Jim <a href="http://as220.org/jb"> My Page</a>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu