[ale] Anyone here who is good with kernel programming?

[David Ritchie]

On Sat, Feb 13, 2010 at 1:16 AM, Michael B. Trausch <mike at trausch.us> wrote:

> That and the media itself is indeed a block-oriented structure.  I could
> be wrong, but I think it's pretty much a requirement that the drive be
> addressed by blocks.  Wouldn't that make it impossible to implement a
> character driver for the CD-ROM driver and perfectly implement character
> device semantics?  Or would it make sense to write the character driver
> and have it "buffer" up to the next block for sequential writes?
>

It has already been done. This is why there are both block and
character devices
associated with disk and tape devices. The block device is used when reading
or writing block  formatted data to the device, while character oriented device
uses the cache to allow standard streams oriented I/O (getc/putc),
which is in turn converted
into block oriented I/O when reading or writing to the tape when a fflush or
close occurs against the device. The primary place this becomes an issue is
when writing tapes, where the blocking actually makes a difference as to how
much data is written, due to intrarecord gaps between each record.
ioctls are typically
used to pass driver specific information and to use device specific capabilities
(for example, writing a tape or file marker to the device). You may
get some of this
for free when the device is opened in character mode, but may need the ioctls
to get desired blocking behavior with tapes.

  The key thing to remember is a disk is not a tape - it doesn't not
have a variable logical/physical
record size, record markers, BOT/EOT markers, you can't rewind a disk,
 and is not a sequential
access device. Use disk drivers to talk to disks, tape drivers to talk
to tape drives. If there wasn't a
difference, they wouldn't have separate drivers in the first place.  I
would recommend reading the
device specific manual pages (mt, st, etc.) , as ioctl operations are
used to pass blocking information
to the drivers and would be crucial to making this all work correctly.

  Optical media is a special case on top of disk, as it has special
protocols involved with
closing the write stream to make it possible to read the media on
another machine, and due
to the fact that many media types are write-once.

   I would suspect that you would have an uphill fight to get any changes merged
into the Linux kernel unless you can show that there is an error or a
performance
problem associated with doing this in the standard ways. If this
change effects  POSIX
specified interfaces, it is even less likely.

  The canonical books on this subject is Richard Stevens' "Advanced
Programming in
the Unix Environment",  and "The Unix Programming Environment" by
Kernighan and Pike.
See http://www.apuebook.com/index.html  and
http://cm.bell-labs.com/cm/cs/upe/ , respectively.
Eric Raymond's "The Art of Unix Programming" may also be useful, and appears to
be available in PDF format online (legality of same is unclear). Like
every other
technical book, all of these are probably also floating around the
bittorrent sites. They
are expensive in dead tree versions, but are the standard.

Best regards,
Dave Ritchie