From: Corey Minyard <minyard@acm.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] IPMI driver for Linux
Date: Wed, 21 Aug 2002 11:52:03 -0500 [thread overview]
Message-ID: <3D63C533.90706@acm.org> (raw)
In-Reply-To: 1029945764.26845.93.camel@irongate.swansea.linux.org.uk
Alan Cox wrote:
>On Wed, 2002-08-21 at 16:47, Corey Minyard wrote:
>
>
>>I have been working on an IPMI driver for Linux for MontaVista, and I
>>think it's ready to see the light of day :-). I would like to see this
>>included in the mainstream kernel eventually. You can get it at
>>http://home.attbi.com/~minyard. It should work on any kernel version,
>>although you will have to fix up the Config.in and Makefile, and the
>>Configure.help stuff may not work (it's currently in the 2.4 location).
>>
>>The web page has documentation on the driver, and documentation is
>>included in the patch, too. This is a fairly full-featured driver with
>>a watchdog, panic event generation, full kernel and userland access to
>>the driver, multi-user/multi-interface support, and emulators for other
>>IPMI device drivers.
>>
>>
>
>Comments in general.
>
>It touches user space with spinlocks held -> bad idea
>
Oops, thanks. I've uploaded a version that fixes this. I only found
one instance of this, but it's pretty bad.
>It doesnt check copy_*_user returns instead commenting that some other
>driver didnt so it wont - bad idea too
>
This was only in the emulation code. I debated about this, but it's
quite possible that doing the check will break the current users of this
code. I'm afraid if I add the checks it will cause other broken code to
not work. I could pull out the emulation code and supply it separately;
I would probably choose to not put that part into the mainstream kernel,
anyway.
>It seems to be allocating a major - can you have > 1 ipmi per host, can
>it use misc devices, can it get one registered properly with lanana
>
Yes, you can have multiple IPMI interfaces on a host (I have a board
that has 3!). There are serial-port interfaces planned that could also
easily have multiple instances as well as an on-board KCS. If there's
an easy way to do this with a minor device, I'm all ears, but I'd prefer
to have a separate device for each interface. This is one of the things
I wanted discussion about. Once that gets settled, I'll go to lanana.
Right now it's just being auto-assigned.
>Otherwise its way way way nicer than the hideous thing a certain chip
>vendor sent me.
>
>
I know what you mean.
Thank you for your response and suggestions.
-Corey
minyard@acm.org
next prev parent reply other threads:[~2002-08-21 16:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-21 15:47 [patch] IPMI driver for Linux Corey Minyard
2002-08-21 16:02 ` Alan Cox
2002-08-21 16:52 ` Corey Minyard [this message]
2002-08-21 19:28 ` Preempt kernel patch for 2.4.19? Jurgen Kramer
2002-08-21 19:32 ` J Sloan
2002-08-21 20:41 ` J Sloan
2002-08-27 14:55 ` [patch] IPMI driver for Linux Pavel Machek
2002-08-27 22:14 ` Matthew Dharm
2002-08-28 2:01 ` Corey Minyard
-- strict thread matches above, loose matches on Subject: below --
2002-08-21 20:41 Larry Butler
2002-08-21 20:53 ` 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=3D63C533.90706@acm.org \
--to=minyard@acm.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.