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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/