On Monday 27 March 2006 05:35, James Harper wrote: > > I'm sure there's a good reason for this, but why is the netdev creation > initiated from userspace? Shouldn't the modules themselves create the > network devices?
The modules just offer a bunch of channels, they don't know a specific channel will be used as D channel or not, it is the userspace who creates a netdevice with lapd protocol and connect it to the D channel. This is much more flexible, you can even connect D channels back to back :) > If that happened, then udev could trigger a script that is called on > creation of the visdnX interface, where the script would configure the > parameters (protocol, role, mode) and then (assuming my thinking is > right) attach the port to it. Obviously this leaves the netdev interface > numbering up to the kernel, but udev supports interface renaming so this > shouldn't pose a significant problem anyway Interfaces renaming is just crazy, you need to have a reserved namespace from which to rename to another namespace to avoid collisions. I was doing that and it looked horrible. > and I think it would be kind of neat to name my netdevs with more meaningful > names :) You can already use any device name you like in the configuration files, just be careful that some hotplug/init/udev scripts in your distro may try to heuristically deduce the type of interface from the name (SuSE, to name one). > So just to summarise my ideas, the configuration would be done as > follows: > > #1 /etc/init.d/visdn loads the core modules at boot (before udev starts > or visdn driver modules are loaded hopefully) No, your distro's coldplug scripts will load the modules which can handle to PCI IDs in your system, with the help of some configuration file when there is more than one module handling the same PCI ID (I4L, mISDN, zaptel, vISDN and drivers). SuSE uses a coldplug script (/etc/init.d/boot.coldplug) and the configuration files are located in /etc/sysconfig/hardware/ > #2 the adapter is detected (either it was already plugged in on boot, or > it has been connected later) and the module is loaded which creates the > required netdevs. A udev/hotplug script will detect when a port object is created, it then looks in a configuration using the "PCI Location + port name" key and creates the corresponding netdev. The netdev may be configured at the same time or another hotplug/udev script is called again on netdev creation and it configures the netdevice by name. > Netdevs are optionally named in the udev rules, > possibly based on of some unique identifier on the card. I think bus > address is the only thing to go on and I have no idea how this works for > usb, which may be a show stopper. The keys you may use to identify a port are: - PCI Location + port name - Card's dip-switches (used as ID) + port name - USB Location + port name - USB Serial Number + port name > #4 if required (and if it's running), the scripts also send a message to > asterisk to re-load the visdn (and optionally extensions) configuration > files. Changes in netdevs are already automatically seen by asterisk by means of netlink messages. > (btw, what is the significance of the port? Eg st0? Have I got my head > on backwards here and the port is the most significant entity and the > netdevs just hang off of it?) A port is a whole physical interface. HFC-A PCI A provide one port, HFC-4S four ports, HFC-8S eight ports, HFC-E1 one port. Their names are decided by the driver, however, the rule is: HFC-S PCI A: st0 HFC-USB : st0 HFC-4S : st0, st1, st2, st3 HFC-8S : st0, st1, st2, st3, st4, st5, st6, st7, st8 HFC-E1 : e1 Bye, -- Daniele Orlandi _______________________________________________ Visdn-hackers mailing list [email protected] https://mailman.uli.it/mailman/listinfo/visdn-hackers
