All of lore.kernel.org
 help / color / mirror / Atom feed
From: odain2@mindspring.com
To: root@chaos.analogic.com
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: proper place for devfs_register_chrdev with pci_module_init
Date: Wed, 4 Feb 2004 16:48:29 -0500	[thread overview]
Message-ID: <200402041648.29096.odain2@mindspring.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0402041616230.3277@chaos>

On Wednesday February 4 2004 4:30 pm, you wrote:
> On Wed, 4 Feb 2004, Oliver Dain wrote:
> > I'm writing a char driver for a PCI card.  Looking at examples of such
> > things I've found that most have a module_init like this:
> >
> > int foo_init(void)
> > {
> > 	/* stuff... */
> > 	devfs_register_chrdev(...);
> > 	/* more stuff... */
> > 	pci_module_init(...);
> > }
> >
> > This seems strange to me.  The devfs_register_chrdev call will register
> > the module and cause it to be held in memory even if the associated
> > PCI device isn't present on the system.  It seems like a better way
> > to do this is to have the init method just call pci_module_init(...)
> > and then in that method, after the PCI device has been initialized, call
> > devfs_register_chrdev to associate the driver with the device.  That way
> > the kernel can unload the module if no such device is present, but if
> > the device is present (or if one appears via hotplug) the module will
> > be loaded and can then register itself.  Will this work?  Is there a
> > reason people don't do this?
>
> First! Fix your mailer. There wasn't a '\n' in the entire bunch
> of text above. Unix/Linux people use the [Enter] key and don't
> just auto-warp around the screen.
>
> > I'm not subscribed to the LKML so please CC me on any responses.
> >
> > Thanks,
> > Oliver
>
> Well the "standard way" to start up a module is to allocate
> resources for the module (like RAM), then register the module.
>
> Then if the device isn't found, it's unregistered and the resources
> freed. If the code to which you refer doesn't free its resources,
> including unregistering if the device isn't found, then it's a bug.
>
> Otherwise it doesn't make any difference. You can certainly probe
> the PCI bus for your device first, and if it isn't found, you just
> return -ENODEV or whatever. It's entirely up to you.
>
> What is important is to make sure that you free any resources
> that you acquired (like address space) if you decide not to
> install the module. This makes it so you can write the module,
> debug it, and add functionality without ever having to re-boot.
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
>             Note 96.31% of all statistics are fiction.

Thanks for the reply and sorry for the mailer issue (sent it from one of those 
pop->web interfaces, not my usual mail client).


If I understand how pci_module_init works it registers a function (the probe 
function) to be called with all harware that matches the id_table.  Thus the 
probe function won't be called at all unless some device matching the the 
parameters passed to it is found.  In that case there is no opportunity to 
unregister the driver since the driver never gets control again.  So I guess 
I could restate my question as:

1) Is it correct that the driver won't get control again if no matching 
devices are found?

2) If that's correct is it "legal" to call devfs_register_chrdev from a 
function other than init (specifically from the probe function)?

Thanks,
Oliver

PS: I'm not subscribed to LKML so please CC responses.


  reply	other threads:[~2004-02-04 21:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-04 20:23 proper place for devfs_register_chrdev with pci_module_init Oliver Dain
2004-02-04 21:30 ` Richard B. Johnson
2004-02-04 21:48   ` odain2 [this message]
2004-02-04 22:29     ` Richard B. Johnson
2004-02-04 23:34       ` Greg KH
2004-02-05 12:42         ` Richard B. Johnson
2004-02-05 15:27           ` Greg KH

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=200402041648.29096.odain2@mindspring.com \
    --to=odain2@mindspring.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /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.