Re: devd limitations / automounting removable storage

From: M. Warner Losh (imp_at_bsdimp.com)
Date: 09/18/03

  • Next message: Poul-Henning Kamp: "Re: devd limitations / automounting removable storage" 
    Date: Thu, 18 Sep 2003 06:52:59 -0600 (MDT)
To: rwatson@freebsd.org

    In message: <Pine.NEB.3.96L.1030917161519.51283B-100000@fledge.watson.org>
                Robert Watson <rwatson@freebsd.org> writes:
    : We might skip the devfs layer since it's probably implicit in the
    : completion of ifnet_attach() and disk_create(), but it's worth thinking
    : about.

    The thing about implicit stuff is that it move knowledge about what is
    created in the driver into userland. This isn't necessarily a good
    thing. For most of the examples talked about, this isn't an issue,
    but what about stranger hardware that creates many devices?

    : This would allow ifconfig commands to be issued once the network
    : device is available, rather than once newbus has attached an xl0.

    network interfaces are available for all drivers in the tree after
    attach finishes. However, interfaces that aren't an exact mirror of
    the hardware don't show up. tun0, for example.

    Also, network interfaces are in a different namespace than newbus
    device names.

    : Or for
    : geom to announce ad0s1e even though newbus doesn't know about it.

    Be careful here. You are confusing two different name spaces. dev_t
    is a third namespace in the kernel. sysctl is another one and of
    course file systems.

    You'd want to know that devfs events have happened in this case. GEOM
    likely doesn't need to get into the mix. And you can likely do that
    with a kqueue on the /dev directory.

    GEOM lives in the dev_t name space (right?)

    : Or for
    : devd to handle the introduction of synthetic interfaces such as vlan, tun,
    : etc, which aren't visible to newbus. Or for the device driver names and
    : interface names to differ (or for a non-one-one mapping, interface
    : renames, etc).

    Yes. devd started out life as a device_t only thing. However, it is
    better viewed as more generalized event dispatcher that currently only
    understand events from device_t entities.

    I was going to point out that there's not a connection between the
    device_t name and the dev_t name, except by convention. Even when
    there is a connection, it can be weird. Device foo0 might create
    /dev/foo0_error and /dev/foo0_data, or other such perverse things.

    Warner
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Poul-Henning Kamp: "Re: devd limitations / automounting removable storage"

    Relevant Pages

    • Re: devd limitations / automounting removable storage
      ... > distinguishing network interfaces at the newbus and network service ... rather than once newbus has attached an xl0. ... > devd to handle the introduction of synthetic interfaces such as vlan, tun, ... has multiple subsystems, like interface, routing, connections. ...
      (freebsd-arch)
    • Re: No Equals on interfaces
      ... >> The OP's sample IMO didn't make sense. ... for interfaces which is definitely not true and thus misleading. ... semantics put on them in general .NET terminology. ... There is nothing implicit for events in VB. ...
      (microsoft.public.dotnet.languages.vb)
    • Re: devd limitations / automounting removable storage
      ... >>Maybe have GEOM send events when mountable entities show up? ... distinguishing network interfaces at the newbus and network service ... rather than once newbus has attached an xl0. ... devd to handle the introduction of synthetic interfaces such as vlan, tun, ...
      (freebsd-arch)
    • Re: Proposal: NOEXTERNAL
      ... You are talking about implicit ... interfaces - not about externals. ... no deficiencies and the other way is to make it so complicated ...
      (comp.lang.fortran)
    • Quantcast