lkml.org 
[lkml]   [2004]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Writing CIS... ioctl?
    Hi.  As a fun little project I'm considering adding userland support 
for reading and writing the CIS block via the SDDR-09. Based on my
previous driver experience, I'd do it using an ioctl on the scsi
device it maps to. However, I'm unsure of how the SCSI/USB layering
occurs and if an ioctl would be the best way to allow access to the
CIS. Note that the CIS info itself is roughly 100 bytes, and that
information is duplicated in another location on the smartmedia card.

Any thoughts? Is an ioctl the way to do it?

Are there other ways that low level control data is written to storage
devices?

For any single project ioctl() is one of the easy ways of doing it.
There are other communication channels, like module parameters
or proc files.

But there are lots of such projects, and after doing a few hundred of them
we have interface mess. For the dev_t change last year I did an audit of
all ioctls, more than a thousand, with lots of different interfaces,
sometimes varying between architectures, not exactly a pleasure.

So, something else is needed, and we do not have it. Lots of ideas have been
suggested. Whatever one does the situation is messy, just because the type
of control needed varies a lot.

If for every device there also is a control device, then the control device
can be opened and ordinary read and write calls can be used. That is good.
But still there will be parsing on both sides, so the mess has only been
hidden a little, it is still there.

Sysfs tries to avoid the parsing problem by having a large number of files,
each with a simple ASCII value. Now one has to walk and parse messy trees.
People who like that will want a control filesystem instead of a control device
for each device.

But you do not want a long discussion, but a utility.

Give the driver a reading and a writing mode.
(Read normal 512-byte blocks, or 512+64-bytes blocks plus control,
or just the 64-byte control, possibly with a choice between 16-byte and
64-byte control, and similarly for write, where write also has the
writeCIS possibility.)

The getting and setting of reading and writing mode is separate from the
rest. While testing, it is probably easiest to use a module parameter.
If everything works, and you want to submit the result for inclusion in the
kernel, see whether Linus has requirements on the shape things should be in.

In case you learn things about the sddr09 hardware not yet documented,
I would like to hear about them.

Andries


[Non-sddr09 examples of control things one wants to do: setmax on a disk;
set a password on a disk; set a disk read-only or read-write (on the
media level or on the drive level or on the software level); eject;
reread partition table; set a ZIP drive to disk vs large floppy mode;
load a keymap; set unicode mode; load a compose table; assign keycodes
to scancode sequences; set keyboard repeat rate; set magic SysRq key.]

-
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/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.042 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site