From: Greg KH <greg@kroah.com>
To: wdebruij@dds.nl
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [ANNOUNCE] various linux kernel devtools : device handling/memory mapping/profiling/etc
Date: Mon, 5 Apr 2004 12:30:04 -0700 [thread overview]
Message-ID: <20040405193004.GA3545@kroah.com> (raw)
In-Reply-To: <1081191622.4071acc6e100c@webmail.dds.nl>
On Mon, Apr 05, 2004 at 09:00:22PM +0200, wdebruij@dds.nl wrote:
>
>
> On Monday 05 April 2004 18:23, Greg KH wrote:
> > I don't see anything in there that will work properly for udev. Am I
> > just missing the code somewhere? Remember, for udev to work, you have
> > to create stuff in sysfs, which I don't see this code doing.
> indeed, automatic creation of the device files is not yet incorporated under
> udev,
Huh?
> but at least it then reverts back to the oldstyle (mknod) device file
> system, right? That's a work in progress as my systems don't actually use
> udev just yet.
I don't think you understand how udev works. Who are you thinking does
the mknod of the device files? udev does it only if it sees a file
called "dev" in sysfs for a device. Your wrapper does not do this at
all (it could be changed to use class_simple to get it, if you so
desired.)
> > Ick, you are using pci_find_device() which is racy, depreciated, and
> > does not play nice with the rest of the kernel. Yes, it's the lowest
> > common denominater accross 2.2, 2.4, and 2.6, but please don't sink to
> > that level if you don't have to. For 2.6 it's just not acceptable.
>
> hmm, really? thanks for the tip. I basically looked at O'Reilly's book
> when I coded that. Do you have a quick alternative for me to use?
pci_register_driver() as Documentation/pci.txt says to use. Works just
wonderful from 2.4 to 2.6, and I think it's even been backported to work
on 2.2 if you so desire.
> > I agree that at times the current kernel driver api learning curve is a
> > bit steep. But people are working to reduce that curve where they can,
> > and it's one of my main priorities for 2.7. Any help and suggestions
> > that you might have in that area are greatly appreciated.
> >
> perhaps some of this code (when cleaned up) can serve as a guide.
Well, feel free to submit portions of it as patches that clean up the
current API, if you think it will help out any. In my short glance, I
didn't really see anything that would help out all that much, but I'm
probably missing something.
thanks,
greg k-h
next prev parent reply other threads:[~2004-04-05 21:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-05 19:00 [ANNOUNCE] various linux kernel devtools : device handling/memory mapping/profiling/etc wdebruij
2004-04-05 19:30 ` Greg KH [this message]
2004-04-06 11:55 ` Willem de Bruijn
-- strict thread matches above, loose matches on Subject: below --
2004-04-05 17:33 wdebruij
2004-04-05 18:23 ` 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=20040405193004.GA3545@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wdebruij@dds.nl \
/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.