RE: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

RE: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Mukker, Atul]

> given that they are completely different from the controller we know
> as megaraid today this is an extremly bad idea.  Just put it 
> into an driver
> of their own, e.g. mptraid
Although, this simplifies the development and maintenance effort, having a
single driver to drive both controllers or two independent drivers is not
always our decision. Most often, it would be Dell's preference. 

> 
> > 2.	Controller and device re-ordering on both lk 2.4 and lk 
> 2.6. If this
> > is not desired, the driver code would be modified to make 
> it PCI ordered
> > detection. The driver also re-orders the drives, based on 
> which one is
> > chosen as boot drive. Matt, please add your comments here.
> 
> This is a bad thing for 2.6, don't do it.  For 2.4 just leave 
> the probe code as
> it is there currently - any change during the stable series 
> just confuses
> users.

So it would be. We would make the controller and devices detection PCI
ordered for 2.6 and preferred ordered for lk 2.4. A patch for unified-alpha1
would be posted for this change soon.


> 
> > 4.	Native hot-plug support for both lk 2.4 and lk 2.6
> 
> hotplug scsi in 2.4 is impossible without a host template per 
> controller
> which you don't seem to do and I'd advice against.
> 
> > 6.	Single code to support *all* x86-32, IA64, and x86-64 platforms
> 
> Umm, it's a PCI card - if it doesn't work on any PCI 
> supporting architecture
> it's a driver bug (either in your driver or the architectures 
> PCI subsysyem)
Currently, IA64 has only 1.18 series of drivers as supported ones. 2.x
driver is not tested on this platform.

RE: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Mukker, Atul]

> I agree with Christoph here.  megaraid is the only driver that I've
> worked with that does this device reordering thing;
Matt, you imply that driver should not do any device re-ordering? I will be
releasing a patch for the unified-alpha1 driver with this change shortly.

Thanks
-Atul Mukker

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

['Christoph Hellwig']

On Wed, Feb 25, 2004 at 03:38:48PM -0500, Mukker, Atul wrote:
> > of their own, e.g. mptraid
> Although, this simplifies the development and maintenance effort, having a
> single driver to drive both controllers or two independent drivers is not
> always our decision. Most often, it would be Dell's preference. 

Well, I think the people at Dell should get down from their fucking crackpipe
then.  (Matt, did you hear that?  please stop this kind of marketing driven
junk, thanks)

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Matt Domsch]

On Wed, Feb 25, 2004 at 08:44:41PM +0000, 'Christoph Hellwig' wrote:
> On Wed, Feb 25, 2004 at 03:38:48PM -0500, Mukker, Atul wrote:
> > > of their own, e.g. mptraid
> > Although, this simplifies the development and maintenance effort, having a
> > single driver to drive both controllers or two independent drivers is not
> > always our decision. Most often, it would be Dell's preference. 
> 
> Well, I think the people at Dell should get down from their fucking crackpipe
> then.  (Matt, did you hear that?  please stop this kind of marketing driven
> junk, thanks)

Yes, I'll try to figure out where this request came from, if from
anyone at Dell.  My guess is it's related to other operating systems,
over which I have no control, but isn't relevant to Linux.

In general, I tend to fight exactly the opposite - people wanting
drivers split out for "new technology" - say, PCI Express, when the
driver<->firmware API hasn't changed, which is just wrong again.

If it's got a different driver<->firmware API, then it needs a new
driver.  If it's the same API, then it should be the same driver.

FWIW, I'm out of the office for the next couple weeks with a new baby,
thus limited sleep and access to people, but I'll discover what I
can, and will take the heat internally for saying "split the driver"
if in fact you've got two different APIs, as I suspect you do.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

RE: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Mukker, Atul]

All,

Thanks a lot for the valuable feedback. The general consensus is against a
single driver for different class of controllers. This would put a strain on
our applications, which expect all the controllers to be exported from
single driver's private ioctl interface.

With multiple adapters, applications would need to open multiple handles.
This would somewhat complicate things for them. But keeping in line with
general expectations, we would fork the drivers for different class of
controllers now.

I have not yet gotten strong feelings against a single driver for lk 2.4 and
lk 2.6. If this is true, we would like to keep single driver for both
kernels - since lk 2.4 still has a big lifecycle.

For lk 2.6, the controllers would be detected PCI ordered and because of
existing lk 2.4 setups, driver would re-order the registration based on boot
controller.

Best Regards
-Atul Mukker
LSI Logic Corporation

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Jeff Garzik]

Mukker, Atul wrote:
>>given that they are completely different from the controller we know
>>as megaraid today this is an extremly bad idea.  Just put it 
>>into an driver
>>of their own, e.g. mptraid
> 
> Although, this simplifies the development and maintenance effort, having a
> single driver to drive both controllers or two independent drivers is not
> always our decision. Most often, it would be Dell's preference. 

If the hardware is similar, a single driver is OK.

If the hardware is not similar, the preference is for separate drivers.

Shared code in a third module, a "library module", is an acceptable 
solution.  modprobe automatically loads dependent modules, so users 
running "modprobe driver1" or "modprobe driver2" would automatically 
load the shared library module.

	Jeff

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Jeff Garzik]

Mukker, Atul wrote:
> With multiple adapters, applications would need to open multiple handles.
> This would somewhat complicate things for them. But keeping in line with
> general expectations, we would fork the drivers for different class of
> controllers now.

"opening multiple handles" is preferred.  You want one discrete object 
per controller or per device, depending on the object in question.


> I have not yet gotten strong feelings against a single driver for lk 2.4 and
> lk 2.6. If this is true, we would like to keep single driver for both
> kernels - since lk 2.4 still has a big lifecycle.

If you are doing multiple drivers in 2.6, it would seem better to match 
that as closely as possible in 2.4.


> For lk 2.6, the controllers would be detected PCI ordered and because of
> existing lk 2.4 setups, driver would re-order the registration based on boot
> controller.

Look at my libata code -- in both 2.4 and 2.6, it uses the proper PCI 
API calls.

Controller order is irrelevant -- device order is what you really care 
about, right?  This can be managed by creating a list during probe, and 
then executing the list after all controllers have been probed. 
Obviously, this excludes hotplug controllers added after the initial 
module_init() function exits.

	Jeff

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Matt Domsch]

On Wed, Feb 25, 2004 at 06:05:43PM -0500, Mukker, Atul wrote:
> Thanks a lot for the valuable feedback. The general consensus is against a
> single driver for different class of controllers. This would put a strain on
> our applications, which expect all the controllers to be exported from
> single driver's private ioctl interface.
> 
> With multiple adapters, applications would need to open multiple handles.
> This would somewhat complicate things for them. But keeping in line with
> general expectations, we would fork the drivers for different class of
> controllers now.

It probably isn't difficult to add this to the applications, but since
I haven't seen the source code to them, it's hard to say.  When I
modified efibootmgr to handle either /proc-style or /sys-style
entries, whichever was present, it wasn't difficult, and really made
the code cleaner.  I wouldn't think your tools would be that much more difficult.

As Jeff hinted, if your userspace<->driver ABI is consistent between
your new MPT-based RAID controllers and your existing megaraid driver,
then perhaps you need a single small helper module (lsiioctl or some
better name), loaded by both mptraid and megaraid automatically, which
handles registering the /dev/megaraid node dynamically.  In this case,
both mptraid and megaraid would register with lsiioctl for each
adapter discovered, and lsiioctl would essentially be a switch,
redirecting userspace tool ioctls to the appropriate driver.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Arjan van de Ven]

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


On Wed, Feb 25, 2004 at 06:05:43PM -0500, Mukker, Atul wrote:
> All,
> 
> Thanks a lot for the valuable feedback. The general consensus is against a
> single driver for different class of controllers. This would put a strain on
> our applications, which expect all the controllers to be exported from
> single driver's private ioctl interface.
> 
> With multiple adapters, applications would need to open multiple handles.
> This would somewhat complicate things for them. But keeping in line with
> general expectations, we would fork the drivers for different class of
> controllers now.

How much private ioctls do you need actually ? I assume that for sending raw
commands you use SG_IO already...

BTW it would be really nice if the various raid controller drivers could
come up with a joint common IOCTL api since it seems every raid controller
driver right now has a largely overlapping but yet different set of ioctls.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Jeff Garzik]

Arjan van de Ven wrote:
> BTW it would be really nice if the various raid controller drivers could
> come up with a joint common IOCTL api since it seems every raid controller
> driver right now has a largely overlapping but yet different set of ioctls.


Well.....   we should be moving away from ioctls for this.

For addressing raid arrays, inject REQ_SPECIAL requests directly into 
the request_queue.

For addressing elements above raid array level (such as when creating 
new arrays, etc.) there should be a character device that talks to the 
host driver.

And please let's not bring that godawful SNIA API into the kernel ;-)

	Jeff

RE: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Mukker, Atul]

 better name), loaded by both mptraid and megaraid automatically, which
> handles registering the /dev/megaraid node dynamically.  In this case,
> both mptraid and megaraid would register with lsiioctl for each
> adapter discovered, and lsiioctl would essentially be a switch,
> redirecting userspace tool ioctls to the appropriate driver.
This seems to me a very interesting idea and good one. We would definitely
explore this idea now and implement. Thanks Jeff, Matt.

-Atul

RE: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Mukker, Atul]

> that you don't do things like
> 
> #if defined(__x86_64__) || defined(__ia64__)
> #endif
> 
> when you really mean
> 
> #ifdef CONFIG_COMPAT
> #endif
What does CONFIG_COMPAT do anyway? We could not find much information about
it's usage

Re: [SUBJECT CHANGE]: megaraid unified driver version 2.20.0.0-al pha1

[Matthew Wilcox]

On Fri, Mar 19, 2004 at 05:17:35PM -0500, Mukker, Atul wrote:
> 
> > that you don't do things like
> > 
> > #if defined(__x86_64__) || defined(__ia64__)
> > #endif
> > 
> > when you really mean
> > 
> > #ifdef CONFIG_COMPAT
> > #endif
> What does CONFIG_COMPAT do anyway? We could not find much information about
> it's usage

CONFIG_COMPAT is defined by the 64-bit architectures when they want to
be able to run 32-bit binaries.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain