On Wed, 2005-16-11 at 16:46 +0100, Stefan Rompf wrote:
> Am Mittwoch 16 November 2005 03:16 schrieb jamal:
>
> > I will not respond to the rest of your email - I wanna make sure we are
> > in sync first on the above. So let me summarize:
>
> Ok, let's see if I understood you:
>
> > 1) There are read_only oper state IFF_XXX flags which are sent via
> > netlink to user space. These are set by the kernel (and not by user
> > space); they reflect the state of "link".
>
> managed only by the device driver or several layers of the device driver.
>
yes.
Caveat:
In the case of a link protocol managed by user space such as 802.1x (or
STP when done properly) - flags from #2 as sent by say the supplicant
user space code will be used to move from dormant<->UP; The real setting
of the read_only flags in #1 however is done in the kernel.
> > 2) There are read/write admin IFF_XXX flags which are used to select
> > the link-oper mode. I made some suggestions in the earlier email and
> > referenced the BSD man pages. By default the state transition is from
> > Down<->UP. A mode could be selected to set a device so it goes from
> > Down<->Dormant.
>
> The setting of link-oper mode tells the kernel how to map the flags from 1)
> to
> 3)
yes.
And at the moment i can only see two modes (default and one that selects
between dormant/down), although we should probably have two bits. Maybe
we can call this something along the lines of IFF_OPMODE.
I dont know if we should enforce that a device be ifdowned first before
setting this or not.
There is one other thing (and the approach doesnt have to be what i
suggest below but i cant see a big variation):
A netif_carrier_on() by a netdevice which has been admin configured to
move between down<->dormant will infact move it to that state and not to
the operational up state. In the case of default mode, (down<->up) it
will move from down->up
> > 3) There is a kernel dev->operstate_kernel which is accessible via
> > user space in the same manner IFF_UP flags are set etc.
>
> Depending on the selected policy in 2), this state is managed by userspace
> and/or kernel and shows the RFC2863 operstate of the device.
indeed.
> Note: To
> accomplish our goal to tell dhcp/router daemons when a device is ready for
> "real" traffic, IFF_RUNNING has to be derived from here.
I think IFF_RUNNING hasnt changed meaning in that it reflects the
operational DOWN/UP state. We may have to export two new IFF_XXX
operational flags to user space {IFF_DORMANT and IFF_LLD} like i was
suggesting earlier; i cant see any other way to escape exporting those
two if we are to maintain backward compat for IFF_RUNNING. Even though
some things ma not make sense, like IFF_RUNNING and IFF_DORMANT being
set together or IFF_RUNNING and IFF_LLD both being set may not make
sense.
> > Lets get in sync with the above first.
>
> All in all, I think my understanding of your idea would work and looks good.
> But if I still didn't get it, it really would be best if you are next in
> posting a patch or pseudo code ;-)
>
I hope the above is clear - any patch will have to be a mix of the ones
posted so far.
If we are in agreement, i can post what i think the states are; although
if we are in agreement above i dont see the need to.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
