[patch] Version 2 of the Linux IPMI driver

[patch] Version 2 of the Linux IPMI driver

[Corey Minyard]

I've cleaned a few things up and fixed some minor bugs.  The only big 
change is renaming the "unused" address to the "system interface" 
address (which makes a heck of a lot more sense).  I'm working on 
userland tools that will tie in to this and to LAN/ICMB stuff, and there 
I saw the need for the name.  I still haven't tested interrupt-driven 
operation, but that's really a rather minor concern since almost no 
boards support it and the driver will work without it.

You can get the patch on my web page at http://home.attbi.com/~minyard, 
relative to 2.5.33 or 2.4.19.  The patch is fairly self-contained, so it 
should be easy to port to other kernel versions.

The lanana guy is not available for a while, so I'm not getting a device 
number in the near future, but I think it's ready for the 2.5 release. 
 Does this need more time, or is it ready for inclusion?

-Corey

Re: [patch] Version 2 of the Linux IPMI driver

[Matthew Wilcox]

> The lanana guy is not available for a while, so I'm not getting a device
> number in the near future, but I think it's ready for the 2.5 release.
> Does this need more time, or is it ready for inclusion?

I don't think you should be using a device number at all.  ioctl is Evil
(TM) and it's perfectly possible to write an IPMI driver which uses
neither an ioctl nor a chaacter device.  Voila:

http://ftp.linux.org.uk/pub/linux/willy/patches/bmc.diff

yes, it was stupid to call it BMC instead of IPMI.  i was handed a pile
of junk that'd been half-heartedly ported from windows.  however, the
principle is sound, you don't need ioctl, nor a character device.

-- 
Revolutions do not require corporate support.

Re: [patch] Version 2 of the Linux IPMI driver

[Corey Minyard]

Matthew Wilcox wrote:

>>The lanana guy is not available for a while, so I'm not getting a device
>>number in the near future, but I think it's ready for the 2.5 release.
>>Does this need more time, or is it ready for inclusion?
>>    
>>
>
>I don't think you should be using a device number at all.  ioctl is Evil
>(TM) and it's perfectly possible to write an IPMI driver which uses
>neither an ioctl nor a chaacter device.  Voila:
>
>http://ftp.linux.org.uk/pub/linux/willy/patches/bmc.diff
>
>yes, it was stupid to call it BMC instead of IPMI.  i was handed a pile
>of junk that'd been half-heartedly ported from windows.  however, the
>principle is sound, you don't need ioctl, nor a character device.
>
>  
>
You access a device as a filesystem?  That's bizarre.  It's a device, 
and they call them "devices" in the kernel for a reason.  Why would you 
want to do this?  Especially with devfs, the whole device numbering 
problem goes away.  You could easily make it a misc device.

Plus, your patch misses a lot of places where IPMI is going.  Many cards 
have multiple IPMI interfaces (I have one that has three).  In 
multi-card systems, IPMI is used for transport for a lot of 
configuration and control information between cards that may be going to 
different applications both inside the kernel and in userland, so a 
straight BMC interface is not going to get you there.  You really need a 
message handler in the kernel.  You could do a message handler in 
userland, but then it makes implementing watchdog timers and I2C 
interfaces kernel interfaces over IPMI much more difficult, and it's a 
message router hooked directly to a device and it makes some sense to 
put it in the kernel.

I toyed with the idea of making it a network interface, since you have 
addressing that is separate from messaging.  However, it probably wasn't 
worth the work for that.

And it wasn't stupid to call your "driver" BMC.  That's exactly what it 
is.  It's not IPMI, it's a KCS BMC interface (hooked in as a filesystem).

-Corey

Re: [patch] Version 2 of the Linux IPMI driver

[Matthew Wilcox]

On Fri, Sep 06, 2002 at 03:25:18PM -0500, Corey Minyard wrote:
> You access a device as a filesystem?  That's bizarre.  It's a device, 
> and they call them "devices" in the kernel for a reason.  Why would you 
> want to do this?  Especially with devfs, the whole device numbering 
> problem goes away.  You could easily make it a misc device.

The point is to get away from using character devices where we don't need
them (and we really don't need them in most places).  Plus, there's no
dependency on devfs with this approach.

> Plus, your patch misses a lot of places where IPMI is going.

Oh, I'm quite aware of the limitations of my driver.  I just don't
want to see yet another character device + ioctl interface going into
the kernel when it's really not necessary.  

> And it wasn't stupid to call your "driver" BMC.  That's exactly what it 
> is.  It's not IPMI, it's a KCS BMC interface (hooked in as a filesystem).

Right, but it should probably be addressed as /dev/ipmi since what we're
doing is sending IPMI messages.

-- 
Revolutions do not require corporate support.

Re: [patch] Version 2 of the Linux IPMI driver

[Greg KH]

On Fri, Sep 06, 2002 at 03:25:18PM -0500, Corey Minyard wrote:
> You access a device as a filesystem?  That's bizarre.

Why?  There's lots of precedent for this model (usbfs, pcihpfs, etc.)

> It's a device, and they call them "devices" in the kernel for a
> reason.  Why would you want to do this?  Especially with devfs, the
> whole device numbering problem goes away.  You could easily make it a
> misc device.

devfs did not make the device numbering problem go away at all, you
still need to have a registered major/minor number with Lanana to use
devfs.  Yes, you can ask for a dynamic misc number, but that is very
difficult to support.

thanks,

greg k-h