public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Matthew Wilcox <willy@debian.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] Version 2 of the Linux IPMI driver
Date: Fri, 06 Sep 2002 15:25:18 -0500	[thread overview]
Message-ID: <3D790F2E.1050306@acm.org> (raw)
In-Reply-To: 20020906201856.F26580@parcelfarce.linux.theplanet.co.uk

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


  reply	other threads:[~2002-09-06 20:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-06 19:18 [patch] Version 2 of the Linux IPMI driver Matthew Wilcox
2002-09-06 20:25 ` Corey Minyard [this message]
2002-09-06 20:36   ` Matthew Wilcox
2002-09-09 17:07   ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2002-09-06 18:35 Corey Minyard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D790F2E.1050306@acm.org \
    --to=minyard@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox