OK. Point taken. I was basically drawing my conclusions
from what's remaining on the public serface of the
overall problem. And there it appears a bit as if it you start
to explode suddenly out of complete silence. At least for me
this was the impression. Unfortunately nobody sees the
silent ping attempt's you are making at the persons in question
before.
> But what would happen if all the drivers were somewhere out in web-land,
> and to find the drivers for your random combination of hardware you'd have
> to search five different web-sites from five different maintainers? Do you
> really think a system can survive that way and find more users? And ever
> be tested as a "sum of all parts"? I don't.
Oh I can only "subscribe myself with both hand's" to this point.
Sure you are right. That's one of the advantages of Linux server systems
over other ones, where you first need to get the basic system...
let's call it M++S++, only to realize that it's already much too old
to be able to support recent hardware, therefore you need to go first
out
and get the wonderfull Severice Phrack number 144. Then you realize that
suddenly the driver for BletherCard from CPR doesn't work with it
becouse the company got out of business before the Phrack 36 was out,
but you still need at least Phrack 140, becouse the Woondeo4DFFFXXX
VGA needs it, and the circle closes.
Sure it's far more advantageous to have a central open developement
point.
However at some point in time it start's to be a disadvantage too.
Lets have a look at the example of the ftape (QIC-80) driver.
First there appeared this driver as an entierly separate entity.
It was long working as a separate patch and then module. (Even since
the times of 1.09.) It was shaky but it worked up to some degree.
Around kernel 1.2 it was impossible to get through to the guy who was
responsible for the developement of it. Someone took over the
maintainance
and persuaded everybody that it should go into the meanline kernel.
And there it is sits since then:
:/usr/src/linux/drivers/char# du ftape
120 ftape/compressor
404 ftape/lowlevel
196 ftape/zftape
780 ftape
Unfortunately thereafter the (second) new maintainer got somehow wild.
He started to implement
things like in-kernel compression and other things like this.
There is a separate
mailing list, there is a separate newsgroup, and so on. Really a lot
of maintainance work. The separately
maintained driver appears to look like the maintainers beloved
playground and the driver has grown like cancer.
He rejected neraly every patch which was just trying to make the whole
thing a bit slimmer at the most obvious places. (For the curious
they are basically maintaining pascal call conventions "emulated" in C
there. At those times the ftape driver was in size
comparable to the rest of my whole running kernel. about 200k here
and about 200k there. Just for a silly simple stiupid Floppy interface
used just once in a month maybe....)
Indeed in the time between there was nearly no synchronization
between the separately maintained thing and the mainstream kernel.
And apparently due to the obsolescence of this technology there
appears to be much less activity on the separately maintained version
too.
Now there is still the code in the main kernel. Albeit this whole
category of devices is alredy entierly out of any practical usefulness.
(I still shake if I only think about how utterly ugly those
whole things, are: serial data transfer over the stepping line
of the floppy controller and later then an ISA-Parport bridge chip on
top
of this to get this peace of crap working as external ...Ugh...
but they where cheap.)
In fact all of the 3 the QIC-80 protocoll based drives I called mine,
at some point in time suddenly stopped to work with the meanline
kernel code, and shortly thereafter where gone to the walhalla
of all the hardware and I didn't by them at day one but from discount
instead. (They where quite OK for data transfer nothing else.)
> So in real life, you need to have a "standard base" that includes all the
> stuff most people are reasonably expected to use. It doesn't include some
> of the more esoteric stuff (hard realtime, specific drivers for hardware
> that exists only in rather special places etc), but it certainly has to
> have drivers for things like a random tulip card, would you not say?
My main point with the above example is that with time some things
get obsolete by age too. If you where really consequent Please
just do rm -rf /usr/src/linux/drivers/char/ftape.
I think the hard realtime stuff has actually by far more users then
this stuff. (At some point in time I meat in Amsterdam some Physicians
who
where pledging for it ;-) And if somebody want's to use those devices he
*will* need
to go to the web for the separately maintained thing anyway!
But there is no point in letting everybody donwloading the kernel
getting it too and waste badwidth with it.
In this case the best kind of maintainance would be just
to leave a pointer to it in linux/Documentation. You already do
the same for much much more important stuff which just happens to
don't run in kernel mode! (lilo, modutils, and many many others...)
What one really needs at a central point is the *current*
common sense for all.
Gosh only some rare nostalgics are still using Amigas
and Ataris ST. No I don't have any problem with this, if they wish and
have fun with it,but I don't see any point in exposing this code through
what
you are calling a "mainstream" kernel. And the code in the "mainstream"
indeed still isn't what one really needs to get them running.
SH processor are by far more interresting those days and
the 2.3 kernels are no longer a good OS choice for an 16 bit CPU.
(I would rather go back to 2.0.xxx if I where looking for a sensible
base for an embedded linux.)
And maybe my proposal to replace really the obsolete drivers
with just a pointer to a place where they are still maintained,
could be considered somehow as a solution to one thing, which
ESR doesn't tell you: How to keep an open project from
turning from an editor into emacs ;-).
In any way it would help to keep the mainstream code base
look less embarassing.
> And maintaining that "standard base" is what I do. Others do it too,
> notably SuSE and Redhat. Much of that "standard base" is based on their
> work, in addition to the obvious work by the actual people who create the
> actual drivers and new features.
>
> But exactly because Linux is _NOT_ a "one entity does everything"
> proposition, it is NOT the case that I go out on the net and find
> everything I want to have in the full package. I very much depend on
> people like David Miller, Alan Cox, Ingo Molnar, and a hundred other
> people who not only maintain their own subsystems, but also help me in
> maintaining those subsystems as part of the larger whole.
>
> The problem in question is when a maintainer maintains the subsystem, but
> does not try to help in maintaining the whole. See? Instant disconnect.
--Marcin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/