[rant] Re: vmware and udev

[Kyrre Ness Sjobak]

man, 22.11.2004 kl. 22.42 skrev Denis Leroy:
> > Denis Leroy wrote:
> > > On a more general note, is there any sort of communications between
> Red
> > > Hat people (who have phones on their desk) and the very few
> companies
> > > that do groundbreaking linux support (Nvidia, VMWare, ...) as far
> as
> > > release schedules and support for new kernel features ? Just
> asking...
> > 
> > To which Arjan van de Ven responded:
> > what you call groundbreaking linux support... I personally consider a
> > major problem... they are 
> > 1) Binary only, and not helping the open source goal at large forward
> > 2) Borderline legal, if at all (my personal opinion is that they are
> not
> > legal, and abusing code I wrote)
> > 3) Lagging behind and even keeping the kernel from going forward at
> times.
> > but.. if you buy a RHEL subscription the support guys you call will
> be
> > happy to work with such vendors on joint problems.
> 
> I know this is a touchy subject :-) and the binary drivers thread
> almost turned into a flame war. Arjan, in your response below you seem
> to be talking about the linux kernel while i was talking about the
> Fedora Core distro, and those are two different things.
> 
> Seems to me, on one side we have the linux kernel developers whose
> interests lie on improving the kernel and adding cool features to it,
> and hereby rely on the strength of the open-source concept in which
> API or ABI changes can be propagated very quickly. This allows the
> kernel to move very fast (unlike other Unices that have been around
> longer) and to maintain a very high level of quality in its
> drivers. They see closed source drivers as an annoyance and hindrance,
> and companies that support them as being capitalistic greedy evil
> entities whose sole purpose is the demise of the Open-Source
> movement. :-)
> 
> On the other hand, we have companies that try to get some leverage out
> of the Linux movement, sometimes in a clumsy fashion, or try to
> respond to their customers demands for Linux support. They are usually
> afraid of the GPL since it's human nature to be afraid of things one
> doesn't fully understand. They usually mean well, but are uneducated
> and completely unprepared for a world in which code is free, having no
> processes in place for it since it hasn't been done before. They see
> kernel developers as pony-tailed hippies who hate their guts and are
> hard to interact with, much less rely on. :-)
> 
> So my question was: shouldn't Fedora stand in the middle ? Shouldn't
> it be the job of putting together a desktop-oriented distribution
> precisely to coordinate the efforts of the various "forces" out there
> (a hard and thankless job IMO), and reach compromises in order to
> provide the best possible desktop experience. This has nothing to do
> with kernel development, but rather in picking the right features to
> use in that kernel without breaking the most popular components,
> coordinating schedules and releases with said components, to make sure
> a Fedora Core release doesn't break the Nvidia drivers (one of those
> most popular components, whether you like it or not) or doesn't happen
> one week before Firefox 1.0 is released. Isn't there somebody in the
> Fedora community (whether he/she's a RedHat employee or not) that
> should be working on this ? His/her job would include calling Nvidia
> and saying something like this "Hi, i work on the Fedora distro. Even
> though our kernel developers hate you, half of our users use your
> drivers and we'd rather not break it for our next release. Is there
> anything we can do?". To which there is or isn't of course, but at
> least somebody's gotta try...
> 
> Anyways, sorry for the long rant :-)


What about having a "plugin" interface for drivers - ie. some hooks in
the kernel where drivers could run as userspace programs, and connect to
the kernel the same ways ex. mp3-plugin hooks up with xmms?

The hook might even be a kernel-module...

Is something like that possible? It would keep a more or less stable API
for external driver devs., maybe not as fast or good as a "real" kernel
driver would be - but still a driver. The processes should maybe run in
some sort of space between userspace and kernelspace... Uid -1? :P - so
it would gain direct access to that HW it *needs* direct access to, an
no more. It might even mean that the need to recompile a module each and
every time you upgrade the kernel is no longer needed.

I don't have the expertice if this is technically possible at all, or
even wanted. Anyone?

Kyrre Ness Sjøbæk, who feels like sticking his head into a snake's nest
of properitary/free and microkernel/monolithic