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
next prev parent 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