From: "Teras Timo (EXT-YomiGroup/Helsinki)" <Ext-Timo.Teras@nokia.com>
To: ext Stephen Hemminger <shemminger@osdl.org>
Cc: ext ext Christoph Hellwig <hch@infradead.org>,
davem@davemloft.net, netdev@oss.sgi.com
Subject: Re: [PATCH] Add ability to register class interfaces for network class
Date: Wed, 27 Oct 2004 22:20:18 +0300 [thread overview]
Message-ID: <20041027192018.GA12845@two.research.nokia.com> (raw)
In-Reply-To: <20041027115538.540de19e@guest-251-240.pdx.osdl.net>
On Wed, Oct 27, 2004 at 11:55:38AM -0700, ext Stephen Hemminger wrote:
> On Wed, 27 Oct 2004 21:38:04 +0300
> "Teras Timo (EXT-YomiGroup/Helsinki)" <Ext-Timo.Teras@nokia.com> wrote:
> > This way the problem is that I have to know which devices I will
> > add the attributes. But the point is to add attributes to
> > all netdevs.
> >
> > Using this approach I'd have to enumerate all the interfaces every
> > now and then.
> >
> > If I have my class interface I get a callback whenever an
> > interface is created or deleted and I can automatically add the
> > attribute to all netdevs.
> >
>
> If you are doing something to all interfaces, then it probably should
> either be part of the common net-sysfs layer, or you can dynamically
> discover and do it by following device transitions with
> register_device_notifier.
I'd like my code to be available as module also so common net-sysfs
is not an option. Hmm... I could use device transitions hooks.
But I'm still a bit puzzled why the interface registration should not
be public?
After all it is only a mechanism to get callbacks whenever a class
device is created or removed. Why to even implement a class interface
system if you are not allowed to use it (except in one special place
where it is considered to be an ugly hack by Christoph Hellwig)?
I understood that the whole point for interfaces is the ability to
extend functionality without core (i.e. common net-sysfs) changes.
Why to lose that modularity?
Cheers,
Timo
prev parent reply other threads:[~2004-10-27 19:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-26 18:35 [PATCH] Add ability to register class interfaces for network class Timo Teräs
2004-10-26 18:48 ` Christoph Hellwig
2004-10-26 20:52 ` Teras Timo (EXT-YomiGroup/Helsinki)
2004-10-27 11:13 ` ext Christoph Hellwig
2004-10-27 11:31 ` Timo Teräs
2004-10-27 15:59 ` Stephen Hemminger
2004-10-27 18:38 ` Teras Timo (EXT-YomiGroup/Helsinki)
2004-10-27 18:55 ` Stephen Hemminger
2004-10-27 19:20 ` Teras Timo (EXT-YomiGroup/Helsinki) [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=20041027192018.GA12845@two.research.nokia.com \
--to=ext-timo.teras@nokia.com \
--cc=davem@davemloft.net \
--cc=hch@infradead.org \
--cc=netdev@oss.sgi.com \
--cc=shemminger@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.