CSMI questions

CSMI questions

[mikem]

All,
I hate to dredge this up again, but, when Eric Moore submitted changes for MPT
Fusion driver containing the CSMI ioctls it was rejected. There was talk on
the linux-scsi list about it being a horrible interface, among other things.
There were also comments about there being a Linux only approach. Personally,
I like that idea but it's not good from a business perspective. Especially
because HP, Dell, and others support more than one OS. Having a unique set of
management apps for each OS would be very cumbersome.

We've also been looking at how to use sysfs rather than ioctls.
 
Some look reasonable, others seem to be restricted by sysfs itself. 
1. only ASCII files are allowed
2. if multiple attributes are contained in one file, who parses out the data?
3. one buffer of size (PAGE_SIZE) may not hold all of the data required

Maybe I'm missing something. If any sysfs experts would like to help me
understand, I'm all ears.

The spec is available at: http://www.t10.org/ftp/t10/document.04/04-345r1.pdf

I'd also like an (brief) explanation of why ioctls are so bad. I've seen the 
reasons of them never going away, etc. But from the beginning of time (UNIX)
ioctls have been the preferred method of user space/kernel communication.

Re: CSMI questions

[Greg KH]

On Tue, Feb 22, 2005 at 11:16:56AM -0600, mikem wrote:
> All,
> I hate to dredge this up again, but, when Eric Moore submitted changes for MPT
> Fusion driver containing the CSMI ioctls it was rejected. There was talk on
> the linux-scsi list about it being a horrible interface, among other things.
> There were also comments about there being a Linux only approach. Personally,
> I like that idea but it's not good from a business perspective. Especially
> because HP, Dell, and others support more than one OS. Having a unique set of
> management apps for each OS would be very cumbersome.

Honestly, the kernel developers don't care about cross-OS platform
management utilities from a business perspective.  :)

> We've also been looking at how to use sysfs rather than ioctls.

Good.

> Some look reasonable, others seem to be restricted by sysfs itself. 
> 1. only ASCII files are allowed

With 1 value in that file.

> 2. if multiple attributes are contained in one file, who parses out the data?

multiple attributes are not allowed to be contained in a single file.

> 3. one buffer of size (PAGE_SIZE) may not hold all of the data required

You have a _single_ attribute that is bigger than PAGE_SIZE?  What is
it?

> I'd also like an (brief) explanation of why ioctls are so bad. I've seen the 
> reasons of them never going away, etc. But from the beginning of time (UNIX)
> ioctls have been the preferred method of user space/kernel communication.

That's because there was no other method.  See the lkml archives for why
ioctls are considered bad, I don't want to dredge it up again.

Hope this helps,

greg k-h

Re: CSMI questions

[Erik Mouw]

On Tue, Feb 22, 2005 at 03:14:50PM -0800, Greg KH wrote:
> On Tue, Feb 22, 2005 at 11:16:56AM -0600, mikem wrote:
> > I'd also like an (brief) explanation of why ioctls are so bad. I've seen the 
> > reasons of them never going away, etc. But from the beginning of time (UNIX)
> > ioctls have been the preferred method of user space/kernel communication.
> 
> That's because there was no other method.  See the lkml archives for why
> ioctls are considered bad, I don't want to dredge it up again.

Here's a quote from the official syndicated kernelnewbies fortunes
file (http://www.kernelnewbies.org/kernelnewbies-fortunes.tar.gz ):

"Basically, ioctl's will _never_ be done right, because of the way people
 think about them. They are a back door. They are by design typeless and
 without rules. They are, in fact, the Microsoft of UNIX."

	- Linus Torvalds on linux-kernel

For the full story, see http://lkml.org/lkml/2001/5/20/81 .


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

CSMI questions

[Miller, Mike (OS Dev)]

Sorry, my last mail went unintentionally.

mikem