> From my experience reading this list, new features that are
> requested that differ from the Linux norm are met sometimes with
> trepidation. If someone wants a feature implemented, it *IS*
> *THEIR* *RESPONSIBILITY* to do so. PERIOD. People aren't paid
> to code, they code WHAT THEY WANT. If you want raw I/O, code it.
> Follow normal coding guidelines, etc.. If your solution truly
> has any technical merit, then and only then when the code is
> written in reality, is it an issue at all. Nobody codes stuff
> for the kernel "because someone else's job depends on it" or
> "because I damned well need it".
>
> If you damned well need it, then damned well code it.
Ummm... Please look at the subject line. What does "PATCH" mean?
Stephen C. Tweedie damned well coded it, and did a fine job too.
> The free development
> community however doesn't give a rats ass for what features Joe
> Blow demands. Their satisfaction comes from the various sources
> cited in Eric Raymonds fabulous papers described above. From
> peer acceptance, self satisfaction, ego boost, sense of
> accomplishment, etc..
Personally, I seek world domination. Someday it could save me from
being stuck with Windows 2000 on my desk at work. I suppose that
could be considered as "self satisfaction", but it requires adding
features that please other people too.
> give up RAW I/O!!!!
>
> Otherwise, next you'll want raw soundblaster port access, video
> access, etc... and then you'll want to disable multitasking
> because the overhead limits the effective speed of single task
> systems. In the end you'll end up with MS-DOS. If that's what
> you want, use it.
Video: how do you imagine XFree86 works?
Multitasking: we already added the FIFO scheduling class.
> So, my posting is to try and make you (and others stuck
> on the RAW I/O thing "see the light". That light is "you want
> it? - You code it". It's nothing new.
ftp://ftp.uk.linux.org/pub/linux/sct/fs/raw-19981210.tar.gz
> If you are offended, it was not my intention.
Well, I am. One of the serious kernel hackers has posted a patch,
complete with rational and performance information. It is a nice
and clean patch that can be extended to support unbuffered access
through the filesystem, yet you write "Write the code".
Serious databases use raw IO to ensure that the data is actually
on the disk before they respond to the client. The operating
system is only there to support administrative software and to
supply device drivers to the database.
Here we have:
1. demand from many scientific and business users
2. justification from an Oracle developer and others
3. code
4. yes, real working code from a well-known kernel hacker
Stephen C. Tweedie (the author) is known for his work on memory
management and filesystems. He did the ext2 read-ahead support.
Being often seen on the Reiserfs mailing list, he is clearly aware
of advanced Linux filesystems. Last I heard, he had been doing
journaling support for ext2.
Considering his qualifications, I trust his judgement on this.
He might understand this issue better than anyone else here.
-
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/