From: Marcel Holtmann <marcel@holtmann.org>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, johannes@sipsolutions.net
Subject: Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
Date: Sat, 05 Sep 2009 07:55:58 +0200 [thread overview]
Message-ID: <1252130158.27694.13.camel@violet> (raw)
In-Reply-To: <20090904214903.49e5a361@nehalam>
Hi Stephen,
> > The Ethernet framing is used for a lot of devices these days. Most
> > prominent are WiFi and WiMAX based devices. However for userspace
> > application it is important to classify these devices correctly and
> > not only see them as Ethernet devices. The daemons like HAL, DeviceKit
> > or even NetworkManager with udev support tries to do the classification
> > in userspace with a lot trickery and extra system calls. This is not
> > good and actually reaches its limitations. Especially since the kernel
> > does know the type of the Ethernet device it is pretty stupid.
> >
> > To solve this problem the underlying device type needs to be set and
> > then the value will be exported as DEVTYPE via uevents and available
> > within udev.
> >
> > # cat /sys/class/net/wlan0/uevent
> > DEVTYPE=wlan
> > INTERFACE=wlan0
> > IFINDEX=5
> >
>
> The problem with your idea is that there is only a nebulous definition of
> what is a Wifi device, and what is a WiMAX device etc. What userspace should be looking
> for is "does device XXX support API yyy?" and if it supports API
> yyy then I it can be configured that way.
We don't need that. We just need to know what technology is behind that
Ethernet device. Otherwise we have no real starting point.
> There already is some information in sysfs like /sys/class/net/XXX/type
> which gives the hardware type (ARPHRD_ETHER, etc). Why not a better version
> of something like this that provides "can do FOO" interface?
that was my initial idea, but I couldn't come up with something good.
And the DEVTYPE from struct device is a standard way of exposing such
information. Actually subsystem like SCSI, USB, Bluetooth etc. use that
already. So why not do the same for Ethernet based devices.
> Doing a several system calls (open/read/close) per device is not a big
> issue. Even an android phone can do open/read/close in less than a millisecond
> I bet.
It is not only the system calls that userspace has to do. There is no
central place for this stuff and why should be do it all if the kernel
already has all the details.
Regards
Marcel
next prev parent reply other threads:[~2009-09-05 5:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-01 7:08 [PATCH] net: Add DEVTYPE support for Ethernet based devices Marcel Holtmann
2009-09-01 7:25 ` Johannes Berg
2009-09-01 7:33 ` Marcel Holtmann
2009-09-05 0:17 ` Marcel Holtmann
2009-09-05 3:27 ` David Miller
2009-09-05 4:34 ` Marcel Holtmann
2009-09-05 4:46 ` David Miller
2009-09-05 5:52 ` Marcel Holtmann
2009-09-05 5:55 ` David Miller
2009-09-05 4:49 ` Stephen Hemminger
2009-09-05 5:55 ` Marcel Holtmann [this message]
2009-09-11 19:37 ` David Miller
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=1252130158.27694.13.camel@violet \
--to=marcel@holtmann.org \
--cc=davem@davemloft.net \
--cc=johannes@sipsolutions.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).