All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] IPMI driver for Linux, version 5
Date: Sat, 12 Oct 2002 14:39:04 -0500	[thread overview]
Message-ID: <3DA87A58.4030409@acm.org> (raw)
In-Reply-To: Pine.LNX.4.33L2.0210112029430.9200-100000@dragon.pdx.osdl.net

Randy.Dunlap wrote:

>On Wed, 9 Oct 2002, Corey Minyard wrote:
>
>| I have put a new version of the IPMI driver on my home page
>| (http://home.attbi.com/~minyard) that removes the Linus-incompatable
>| typedefs.  The only typedefs left are "handle" ones.
>|
>| PS - In case you don't know, IPMI is a standard for system management,
>| it provides ways to detect the managed devices in the system and sensors
>| attached to them.  You can get more information at
>| http://www.intel.com/design/servers/ipmi/spec.htm
>| -
>
>
>Hi Corey,
>
>Thanks for eliminating most of those typedefs.
>What is a handle, and why did you leave those?
>
Those are the things that I don't want the user to care what they are, 
they just identify the IPMI user to the layer.  In the future, I could 
change them to an integer, or a small structure, or whatever.

I messed up, though, and didn't change the typedef to be
  typedef struct ipmi_user *ipmi_user_t.
I'm going to do that on a release by monday.

>I applied and built this on 2.5.41 (in-kernel and modular).
>Only one compile warning:
>## drivers/char/ipmi/ipmi_kcs_sm.c:234: warning: implicit declaration of function 'memcpy'
>
>Alan has reviewed this driver, right?  (at least an earlier
>version of it)
>
He has at least done a cursory review of the driver.  I'm not sure where 
he stands with it now.

>And you are asking for a major device number assignment?
>
I think I am going to only do dynamic assignment of the major number. 
 Someone else is looking at a filesystem interface for it, and I am also 
looking at doing a socket interface.  There seems to be some resistance 
to having a character driver for this (although I'm not exactly sure how 
to take it) and a socket interface may make more sense.

>
>I believe that this driver is in pretty good condition for
>addition to the 2.5 kernel.
>
We need to at least resolve the interface issues.

>
>Specific comments below, each beginning with "##".
>
>Warning to others: long-ish.
>
>~Randy
>
>
>+++ linux/drivers/char/Config.help	Fri Sep 20 08:37:00 2002
>
>+CONFIG_IPMI_EMULATE_RADISYS
>+  This enables emulation of the Radisys IPMI device driver.
>+CONFIG_IPMI_EMULATE_INTEL
>+  This enables emulation of the Intel IMB device driver.
>
>## These CONFIG_'s aren't used.  Can be removed from help file
>## unless there is code to be added for them.
>
Oops, that was a mistake.  They should only be in the emulation file.

>
>+++ linux/drivers/char/ipmi/Makefile	Thu Aug 22 20:58:47 2002
>
>+O_TARGET	:= built-in.o
>## delete O_TARGET for 2.5.lately
>
>+list-multi := ipmi_kcs_drv.o
>## delete list-multi for 2.5.lately
>
Ok.  I'll look at this for 2.5.

>
>+++ linux/drivers/char/ipmi/ipmi_devintf.c	Wed Oct  9 14:38:56 2002
>
>+static int init_ipmi_devintf(void)
>## use __init here.
>+{
>+	int rv;
>...
>+	rv = ipmi_smi_watcher_register(&smi_watcher);
>+	if (rv) {
>+		printk(KERN_WARNING "ipmi: can't register smi watcher");
>##  need to undo/return/free anything here ?? (see cleanup_ipmi())
>+		return rv;
>+	}
>+}
>
Yes, the devfs handle and char device are now released properly.

>
>+#ifdef MODULE
>##  don't need this #ifdef
>+static void cleanup_ipmi(void)
>##  use __exit here
>+{
>+	ipmi_smi_watcher_unregister(&smi_watcher);
>+	devfs_unregister(devfs_handle);
>+	unregister_chrdev(ipmi_major, DEVICE_NAME);
>+}
>+module_exit(cleanup_ipmi);
>+#else
>## #ifndef MODULE (or nothing since it's __init)
>+static int __init ipmi_setup (char *str)
>+{
>...
>+}
>+#endif
>
Ok.

>
>+++ linux/drivers/char/ipmi/ipmi_kcs_intf.c	Wed Oct  9 14:38:56 2002
>
>+	/* Flags from the last GET_MSG_FLAGS command, used when an ATTN
>+	   is set to hold the flags until we are done handling everything
>+	   from the flags. */
>+	unsigned char       msg_flags;
>#define RECEIVE_MSG_AVAIL	0x01
>#define EVENT_MSG_BUFFER_FULL	0x02
>#define WDT_PRE_TIMEOUT_INT	0x08
>## and use these instead of magic numbers when testing <msg_flags> below.
>
>+static int init_ipmi_kcs(void)
>## use __init
>
>+#ifdef MODULE
>+void cleanup_one_kcs(struct kcs_info *to_clean)
>## use __exit
>
>+static void cleanup_ipmi_kcs(void)
>## use __exit
>
Fixed all the above.

>
>+++ linux/drivers/char/ipmi/ipmi_kcs_sm.c	Fri Aug 23 12:03:31 2002
>
>+/* The states the KCS driver may be in. */
>+typedef enum kcs_states_e {
>...
>+} kcs_states_t;
>## still have typedefs
>
>+int kcs_get_result(kcs_data_t *kcs, unsigned char *data, int length)
>+{
>...
>+		data[2] = 0xc6; /* Report a truncated error.  We might
>+                                   overwrite another error, but that's
>+                                   too bad, the user needs to know it
>+                                   was truncated. */
>## use #defines (with useful names) for magic values
>
>+int kcs_size(void)
>+{
>+	return sizeof(kcs_data_t);
>+}
>## why a function ? maybe inline in a header file ?
>
This was done like this because I don't want the user to have access to 
the contents of the structure.

>
>+++ linux/drivers/char/ipmi/ipmi_kcs_sm.h	Fri Aug 23 11:21:44 2002
>
>+typedef struct kcs_data_s kcs_data_t;
>+typedef enum kcs_result_e
>+{
>...
>+} kcs_result_t;
>## still have typedefs
>
>+/* Return the size of the KCS structure in bytes. */
>+int kcs_size(void);
>## put inline here.
>
>+++ linux/drivers/char/ipmi/ipmi_msghandler.c	Wed Oct  9 14:38:56 2002
>
>+int ipmi_request(ipmi_user_t      *user,
>+		 struct ipmi_addr *addr,
>+		 long             msgid,
>+		 struct ipmi_msg  *msg,
>+		 int              priority)
>+{
>+	return i_ipmi_request(user,
>+			      user->intf,
>+			      addr,
>+			      msgid,
>+			      msg,
>+			      NULL, NULL,
>+			      priority);
>+}
>## why not inline ?
>
>+int ipmi_request_supply_msgs(ipmi_user_t          *user,
>+			     struct ipmi_addr     *addr,
>+			     long                 msgid,
>+			     struct ipmi_msg      *msg,
>+			     void                 *supplied_smi,
>+			     struct ipmi_recv_msg *supplied_recv,
>+			     int                  priority)
>+{
>+	return i_ipmi_request(user,
>+			      user->intf,
>+			      addr,
>+			      msgid,
>+			      msg,
>+			      supplied_smi,
>+			      supplied_recv,
>+			      priority);
>+}
>## why not inline ?
>
Not a big deal, but I made it inline.

>
>## Lots of pre-function comments throughout the driver(s) should be in
>## typical kernel style, like this one copied from kernel/exit.c:
>/*
> * Send signals to all our closest relatives so that they know
> * to properly mourn us..
> */
>## as compared to:
>+/* Handle a new message.  Return 1 if the message should be requeued,
>+   0 if the message should be freed, or -1 if the message should not
>+   be freed or requeued. */
>
I'll fix these later.

>
>+static int has_paniced = 0;
>## why are these (data, code) not inside CONFIG_IPMI_PANIC_EVENT ?
>## along with notifier_chain_[un]register() calls ?
>## except do it _without_ #ifdefs in the middle of functions.
>## i.e., hide the #ifdefs in a header file.
>+static int panic_event(struct notifier_block *this,
>+		       unsigned long         event,
>+                       void                  *ptr)
>+{
>+	int        i;
>+	ipmi_smi_t *intf;
>+
>+	if (has_paniced)
>+		return NOTIFY_DONE;
>+	has_paniced = 1;
>+
>+	/* For every registered interface, set it to run to completion. */
>+	for (i=0; i<MAX_IPMI_INTERFACES; i++) {
>+		intf = ipmi_interfaces[i];
>+		if (intf == NULL)
>+			continue;
>+
>+		intf->handlers->set_run_to_completion(intf->send_info, 1);
>+	}
>+
>+#ifdef CONFIG_IPMI_PANIC_EVENT
>+	send_panic_events();
>+#endif
>## hide this #ifdef in a header file.
>+
>+	return NOTIFY_DONE;
>+}
>
>+static int ipmi_init_msghandler(void)
>+{
>...
>+	notifier_chain_register(&panic_notifier_list, &panic_block);
>## should be conditional on CONFIG_IPMI_PANIC_EVENT
>
Nope.  I need to know if a panic has occurred so I can through the state 
machines into run-to-completion mode.  This way, watchdog messages and 
stuff like that can go out.  The panic event stuff only affects the 
generation of the IPMI event upon a panic.  There are other reasons for 
knowing when a panic happens.

>
>+#ifdef MODULE
>## don't need this #ifdef
>+static void cleanup_ipmi(void)
>## use __exit
>
>+	notifier_chain_unregister(&panic_notifier_list, &panic_block);
>## should be conditional on CONFIG_IPMI_PANIC_EVENT
>
>+++ linux/drivers/char/ipmi/ipmi_watchdog.c	Wed Oct  9 14:38:56 2002
>
>+static void ipmi_wdog_pretimeout_handler(void *handler_data)
>+{
>+	panic("Watchdog pre-timeout");
>## why panic on a pre-timeout condition ?
>
>+#ifdef MODULE
>+static void ipmi_unregister_watchdog(void)
>## can be __exit
>
>+++ linux/include/linux/ipmi.h	Wed Oct  9 14:38:56 2002
>
>+#ifdef __KERNEL__
>## why is this needed?  kernel headers shouldn't be used in userspace.
>
It doesn't hurt anything, and it's nice to be able to use the same 
include files.

>
>+typedef struct ipmi_user_s ipmi_user_t;
>## remove typedefs
>
This will become a typedef of a pointer.

>
>+/*
>+ * The userland interface
>+ */
>## userspace interface in a kernel header file ??  not good.
>
You have to define the userland interface somewhere so the kernel knows 
what to export :-).

>
>+++ linux/include/linux/ipmi_smi.h	Wed Oct  9 14:38:56 2002
>
>+typedef struct ipmi_smi_s ipmi_smi_t;
>## remove typedefs
>
This will become a typedef of a pointer.

>
>+++ linux/kernel/ksyms.c	Fri Sep 20 08:37:16 2002
>
>+EXPORT_SYMBOL(panic_notifier_list);
>## don't need this.  (it's already extern; build works without this)
>
The module will not load without this.  It is quite necessary.


Thanks for the input, I will fix the ones I identified as problems.

-Corey



      reply	other threads:[~2002-10-12 19:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-09 20:23 [PATCH] IPMI driver for Linux, version 5 Corey Minyard
2002-10-12  3:32 ` Randy.Dunlap
2002-10-12 19:39   ` Corey Minyard [this message]

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=3DA87A58.4030409@acm.org \
    --to=minyard@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.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.