Re: [PATCH] cciss: add passthrough ioctl

Re: [PATCH] cciss: add passthrough ioctl

[Stephen Cameron]

Arjan van de Ven (arjanv@redhat.com) wrote:

> On Mon, 2003-03-03 at 05:38, Linux Kernel Mailing List wrote:
> > ChangeSet 1.1058, 2003/03/02 20:38:36-08:00, akpm@digeo.com
> > 
> >  [PATCH] cciss: add passthrough ioctl
> >  
> >  Patch from Stephen Cameron <steve.cameron@hp.com>
> >  
> >  Add new big passthrough ioctl to allow large buffers.  Used by e.g.  onl ine
> >  array controller firmware flash utility.
> 
> WHY?
> 
> didn't 2.5 have a generic method of doing this instead of weird per
> driver ioctls ?
> 

Show me how.  There are devices that may talked to through the per 
driver passthrough interface which are not normally exposed to linux.  
E.g.  the driver presents the "logical drives" to linux.  I can imagine
that these may be talked to through some generic interface because these
devices are exposed to linux (though there is still a mapping from SCSI-3
addressing to scsi-2 addressing).

But, there are the physical drives which comprise those logical volumes
(e.g. the drives which make up a mirrored logical drive or a RAID5 set
etc.)  Those devices are not exposed to linux in any way.  The only way
to talk to them directly (for example to upgrade firmware on them) is
thourgh this interface,  Likewise for talking to the controller itself
(e.g. again to upgrade firmware for example.).

Also, we can connect external array controllers to the 
internal array controller HBA, and talk to those external 
controllers through this interface.  (for normal disk i/o
to those external controllers, nothing special is needed as
the logical drives on those controllers are magically presented
by the firmware in the HBA as just more logical volumes.)

Examples of applications which want to use this interface:

Online array configuration utiltiy.  Allows you to create new
logical drives (e.g. add new disks and actually use them, that
would be the main feature, but lots of others.  e.g.: online 
volume migraction  (turning a raid-0 logical drive into a raid1, 
or a raid 5, etc, while i/o continues.)

CIM agents, for monitoring health of physical drives, external
storage boxes, etc.

Updating firmware.

Now, you may ask the question, why the "Big" passthrough
ioctl in addition to the "regular" one that's already there.

Because, in order to flash the array controller firmware,
it's got to be done that way...

You then can ask the question why not remove the regular
passthrough ioctl than?

Because we don't want to break the apps that rely on it.

If that's not a good enough reason?  Well, it's not my
kernel, who am I to say?  Break what you will.

-- steve

Re: [PATCH] cciss: add passthrough ioctl

[Arjan van de Ven]

On Mon, Mar 03, 2003 at 09:26:40AM +0600, Stephen Cameron wrote:
> Because, in order to flash the array controller firmware,
> it's got to be done that way...

I don't buy this. Sorry. What's against creating a device for this
controller itself ? 
(And yes, the kernel could use a formal ioctl number for "upgrade firmware") 

Re: [PATCH] cciss: add passthrough ioctl

[Alan Cox]

On Mon, 2003-03-03 at 15:27, Arjan van de Ven wrote:
> On Mon, Mar 03, 2003 at 09:26:40AM +0600, Stephen Cameron wrote:
> > Because, in order to flash the array controller firmware,
> > it's got to be done that way...
> 
> I don't buy this. Sorry. What's against creating a device for this
> controller itself ? 
> (And yes, the kernel could use a formal ioctl number for "upgrade firmware") 

All the other devices supporting firmware upgrade use ioctls for it. Its one
of those suitably obscure things where you don't care too much about the api
and you certainly don't want to get the wrong device!

Re: [PATCH] cciss: add passthrough ioctl

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Mon, 2003-03-03 at 05:38, Linux Kernel Mailing List wrote:
> ChangeSet 1.1058, 2003/03/02 20:38:36-08:00, akpm@digeo.com
> 
> 	[PATCH] cciss: add passthrough ioctl
> 	
> 	Patch from Stephen Cameron <steve.cameron@hp.com>
> 	
> 	Add new big passthrough ioctl to allow large buffers.  Used by e.g.  online
> 	array controller firmware flash utility.

WHY?

didn't 2.5 have a generic method of doing this instead of weird per
driver ioctls ?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: [PATCH] cciss: add passthrough ioctl

[Cameron, Steve]

> On Mon, Mar 03, 2003 at 09:26:40AM +0600, Stephen Cameron wrote:
> > Because, in order to flash the array controller firmware,
> > it's got to be done that way...
> 
> I don't buy this. Sorry. What's against creating a device for this
> controller itself ? 
> (And yes, the kernel could use a formal ioctl number for "upgrade firmware") 

Arg.  Now I wish I didn't already port that code to 10 distributions.
Please shoot me.

How do you want it done?

-- steve

RE: [PATCH] cciss: add passthrough ioctl

[Alan Cox]

On Mon, 2003-03-03 at 16:17, Cameron, Steve wrote:
> 
> > On Mon, Mar 03, 2003 at 09:26:40AM +0600, Stephen Cameron wrote:
> > > Because, in order to flash the array controller firmware,
> > > it's got to be done that way...
> > 
> > I don't buy this. Sorry. What's against creating a device for this
> > controller itself ? 
> > (And yes, the kernel could use a formal ioctl number for "upgrade firmware") 
> 
> Arg.  Now I wish I didn't already port that code to 10 distributions.
> Please shoot me.
> 
> How do you want it done?

I really think it should stay as it is for now. Maybe in 2.7 we need to have
the firmware update argument, but we need to have it about *all* related
drivers and do it once and right.