Jamal's address ommited as requested.
Stefan Rompf <[EMAIL PROTECTED]> writes:
> I'm more unhappy about the fact that a driver can (and could) do a
> netif_carrier_off()/-on() sequence too fast for the workqueue to follow.
Precisely. So there will always be the "glitches". And we can't "fix"
it. Nor, IMHO, we need to fix it.
> But
> changing this requires major surgery in netdev_state_change() and hey, I'm
> not a networking core guru.
It would be a massive unneeded overkill. Not a rocket science, though.
BTW: Nobody knows all the networking.
> I only plead guilty for willing to solve both your
> problem and userspace interaction. And I think we have reached a compromise
> that is acceptable for both. So no need for flaming.
Well, I just reread all the thread(s). I think it just went the wrong
way. What do we have now? We don't have clearly defined goals. You try
a (impossible?) compromise between my bit flags and SNMP (userspace
interaction is another story and is equally possible with any
implementation). You (Stefan and Thomas) have/had some ideas, some of
which were broken and some were not. Not sure about Jamal - I'm not sure
what does he mean with 50% of his mail and he don't like to show
code/ideas.
Summary from my POV:
1. we don't necessarily need to fix all problems at once but we should
leave a clear way
2. we don't need to hurry - better do it correctly than faster
3. we don't want to fix userspace "glitches" (leaking RUNNING to userspace)
4. if 3) then we don't want to fix kernel "glitches" as they will be much
shorter (usually interrupt-driven) and nothing sensitive will see them
5. we really want to have it applied to the official kernel, making
patches which have no chance to be accepted is nonsense.
6. we don't want to break existing semantics - especially those related
to Ethernet drivers (and the existing semantics are IMHO correct).
7. I'm not convinced we should do SNMP-alike things in the kernel. It can
be done in userspace.
8. While I think the dormant state should have a common entry point for
both userspace and kernel drivers (such as netif_protocol_*()) I agree
we should provide means for kernel drivers to easily export it to
userspace (i.e., driver would need a simple operation to enable
userspace changing dormant/protocol state).
9. I think userspace access to dormant/protocol state must be first
enabled by the device.
Other issues:
8. automatic skipping of routes which use non-RUNNING interface ("inactive
routes").
9. if 7) then DORMANT L3 UP and DOWN states (flag etc.). I still think
it's a good idea, even if initially omitted. I'd just add another
flag bit, something like IFF_UP + IFF_RUNNING + IFF_NOT_YET_CONNECTED
(probably not the best name).
10. Less locking, more simplicity, the better.
I no longer think netlink should be used for signaling userspace status
to the kernel. I think it should:
a) export kernel device status (admin, carrier, kernel protocol) using
ioctl() (userspace polling) and additionally (optionally used by
userspace) netlink. Both already exist so no (big) changes here.
b) ioctl() should be used for changing in-kernel state. It should go
through the kernel driver, with a simple wrapper.
a - userspace can request device status at any time. Netlink support
may be used to reduce latency but polling + ioctl() should be used to
get actual status.
b - we need reliable signaling. ioctl() is reliable. Something like:
linux/drivers/net/xxx.c device initialization:
dev->do_ioctl = device_ioctl;
device_ioctl(args...)
{
switch(cmd)
case SIOC_SET_USERSPACE_STATUS:
if (ifr->value == UP)
netif_protocol_up(dev);
else
netif_protocol_down(dev);
It also allows for a case when both kernel protocol driver and userspace
part want to control dormant state / protocol flag.
--
Krzysztof Halasa
-
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
