Of course it will be ``yes'', it's just the next natural step for
an ever maturing (great!) OS. ``Ordering'' is implicitly preserved
in the buffer cache (read/write (2)), but DB/Journalled FS would
want a finer access to the device (imagination use req'd here).
And there's plenty of (old) research there on queuing models
which would provide that kind of flexibility for that future time
when there'd be ``oui'' :-).
> > I've already written one OpenSource SCSI mid-layer, given
> > presentations on how to fix the Linux mid-layer, and try to discuss
> > these issues with Linux developers. I just don't have the energy to
> > go implement a real solution for Linux only to have it thrown away.
> > Life's too short. 8-)
>
> What can I say? I've always found the life of an open source developer to be a
> pretty thankless, filled with bug reports, irate complaints about feature
> breakage and tossed code. The worst I think is "This code looks fine now why
> don't you <insert feature requiring a complete re-write of proposed code>".
>
> I can ceratinly sympathise with anyone not wanting to work in this
> environment. I just don't see it changing soon.
Oh, c'mon James. You know we all appreciate you very much, no need for this.
The reason some of us have not started meddling with SCSI core is that
same appreciation of the other ppl working on it, the trust and good rapport.
Linux SCSI is one of the great environments, cf. <you know where'd I refer>.
I'm happy and proud to be part of this environment.
Probably what Justin meant is some past events in the history of Linux,
and the best course of action would be a LaTeX/PS/ASCII presentation/layout/blurb
of what Justin had in mind, and we can start from there.
-- Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/