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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox