public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PATCH 2.4.0.10: Update hotplug
Date: Thu, 02 Nov 2000 20:35:42 -0800	[thread overview]
Message-ID: <00fe01c0454f$872bee30$6500000a@brownell.org> (raw)
In-Reply-To: <007401c04527$dc094510$6500000a@brownell.org> <3A020920.4559F400@mandrakesoft.com>

> >     - Changing /sbin/hotplug invocations ... now it can
> >       only support "add" and "del" events.  (USB now
> >       uses "add" and "remove", though "remove" doesn't
> >       try to do anything yet.)
> > 
> >       This removes the intended flexibility whereby
> >       different subsystems (such as networking) can
> >       define their own events.
> 
> Wrong.  Different subsystems -do- define their own events. 

I can't read your documentation that way, and you changed
some code that currently passes arbitrary event names into
code that passes magic numbers (0/1 for add/del).


>     However,
> different subsystems should use the same verbs for the same actions.
> We need consistency where possible.

So why change how it's _already_ being done?  And why change
the current policy about the use of /sbin/hotplug parameters?
(Described in kmod.c and the link from HOTPLUG config help.)

It's not that change is bad, but without motivation this one
seems to be gratuitous.  Why impose conversion costs, then?


> >     - "/sbin/hotplug net ..." replaced by "/sbin/network",
> >       with two custom event types.
> 
> Hotplug device insertion and network interface addition/removal are two
> fundamentally different things. 

No, they're the same thing at different levels.  It's telling
a subsystem to react to some entity that wasn't there before,
or which is going away:  hot plugging and unplugging.

You can easily see this by considering what happens when you
connect a USB network adapter.  (Similarly for a Cardbus one.)
Two invocations are needed:

    - From the USB subsystem:  "/sbin/hotplug usb add" tells
      usermode USB tools about the new USB device entity.

      At this level, tools know they _may_ need to choose and
      load a (network) driver; or, it might be in the kernel
      already, needing special setup (maybe load microcode
      or start a special service).  In this case, the driver
      creates a new network interface entity.

    - From the network subsystem:  "/sbin/hotplug net add"
      tells usermode networking tools about the new interface.

      At this level, tools know they may need to activate an
      existing configuration ("ifup eth0") or perhaps alert
      a sysadmin to create a new config.

They're just different subsystems; the "new thing!" alert is
the same event role in both cases.  No matter that the "thing"
differs (USB device vs. network interface) and that the event
receiver differs (USB tools vs. network tools).

If there is going to be any abstraction at all, it's got to be
blind to those particular details ... else every new subsystem
and device type will get new hotplug commands in /sbin and in
/proc/sys/kernel, with eventual chaos.


>     Further, my code purposefully does not
> wrap CONFIG_HOTPLUG around the /sbin/network code,

As we discussed separately, the CONFIG_{HOTPLUG,KMOD} coupling
there isn't quite separable because of how kmod works today.

You'll need CONFIG_HOTPLUG and CONFIG_KMOD unless you shift
some of the guts of kmod; which should happen, but maybe now
isn't the right time for that.


>     because /sbin/network
> has utility outside the domain of hotplug.

Again, not according to the documentation you included; but
then, it doesn't really talk about /sbin/network except to
say that it's used to report additions/removals.  Which is
what /sbin/hotplug was defined to handle ... :-)

- Dave





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-11-03  4:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-02 23:51 PATCH 2.4.0.10: Update hotplug David Brownell
2000-11-03  0:38 ` Jeff Garzik
2000-11-03  4:35   ` David Brownell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-11-02  8:05 Jeff Garzik
2000-11-02  8:01 ` David S. 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='00fe01c0454f$872bee30$6500000a@brownell.org' \
    --to=david-b@pacbell.net \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.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