Re: cloning network interfaces
On Mon, Jun 25, 2001 at 01:31:06AM +0900, Hajimu UMEMOTO wrote: It seems fine to me. I just tried it on my box. You forget to include prototype change of in_gif_input() in sys/net/if_gif.h. It's defined in sys/netinet/in_gif.h and I forgot to include it in my diff. Sorry about that. BTW, why did you change gif_ioctl() to gif_ifioctl()? gif related modules are shared among *BSDs and maintained in KAME CVS repository. Could you please keep local changes small as possible? I had renamed it when I introduced the /dev/gif device and an ioctl for that. I just forgot to rename it. Sorry about that. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: cloning network interfaces
On Fri, 22 Jun 2001 12:51:13 -0700
Brooks Davis [EMAIL PROTECTED] said:
brooks Ok, after a week and a half of doing other things, I've got a patch
brooks together which adds interface cloning based on NetBSD's code. The
brooks difference is that you may pass an interface of the from gif# if you
brooks don't need a specific number. The ioctl now returns a potentialy
brooks modified ifreq which contains the new interface name. This changes the
brooks way drivers implement cloning in that they may return a different unit
brooks then they were passed and they must do their own resource management
brooks rather then relying on the clone functionality in sys/net/if.c to do it
brooks for them.
brooks The patch is at:
brooks http://people.freebsd.org/~brooks/patches/gif.diff
brooks The patch can be applied as follows (you need to make the directories):
brooks cd /usr/src
brooks mkdir sys/modules/if_gif sys/modules/if_stf
brooks patch /tmp/gif.diff
brooks The patch does the following:
brooks - adds interface cloning support to the kernel
brooks - adds interface cloning support to ifconfig
brooks - makes gif clonable
brooks - makes gif usable as a module
brooks - removes the need for NGIF and gif.h
brooks - removes va_args usage in in_gif_input to remove a warning
brooks - removes gif dependencies from stf
brooks - makes stf usable as a module
It seems fine to me.
I just tried it on my box. You forget to include prototype change of
in_gif_input() in sys/net/if_gif.h.
BTW, why did you change gif_ioctl() to gif_ifioctl()? gif related
modules are shared among *BSDs and maintained in KAME CVS repository.
Could you please keep local changes small as possible?
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
On Wed, Jun 13, 2001 at 04:07:16AM +0900, Hajimu UMEMOTO wrote: I like your idea. I'm serving tunnel broker using DTCP (Dynamic Tunnel Configuration Protocol) in our ISP. So, I'm grad if we have dynamic gif creation, too. Ok, after a week and a half of doing other things, I've got a patch together which adds interface cloning based on NetBSD's code. The difference is that you may pass an interface of the from gif# if you don't need a specific number. The ioctl now returns a potentialy modified ifreq which contains the new interface name. This changes the way drivers implement cloning in that they may return a different unit then they were passed and they must do their own resource management rather then relying on the clone functionality in sys/net/if.c to do it for them. The patch is at: http://people.freebsd.org/~brooks/patches/gif.diff The patch can be applied as follows (you need to make the directories): cd /usr/src mkdir sys/modules/if_gif sys/modules/if_stf patch /tmp/gif.diff The patch does the following: - adds interface cloning support to the kernel - adds interface cloning support to ifconfig - makes gif clonable - makes gif usable as a module - removes the need for NGIF and gif.h - removes va_args usage in in_gif_input to remove a warning - removes gif dependencies from stf - makes stf usable as a module -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: cloning network interfaces
On Mon, 11 Jun 2001 14:20:31 -0700
Brooks Davis [EMAIL PROTECTED] said:
brooks On Sun, Jun 10, 2001 at 11:29:07PM +0900, Hajimu UMEMOTO wrote:
I think it is not BSD network way. Recent NetBSD has network
interface cloning. It uses SIOCIFCREATE and SIOCIFDESTROY. It may
good to port it to FreeBSD.
brooks I've looked it over and I generally like it. There is one problem
brooks though. That's the requirement that you use static units. The problem
brooks with this is that it forces you to implement free unit scanning in
brooks userland if you just want to create a unit and don't care what it is.
brooks If you have to do this, and things are being changed at any kind of
brooks significant rate, you have race condition between scanning the
brooks interface list for a free unit and trying to allocate it. This race can
brooks theoreticaly lead to starvation.
I see.
brooks My proposed solution is threefold. First, change the ifc_create pointer's
brooks type to:
brooks int (*ifc_create)(struct if_clone *, int *);
brooks so you can return a unit if the caller requests a wildcard unit (by
brooks passing -1). Second, move unit management in to the driver rather then
brooks just using ifunit in if_clone_create. Drivers could choose to implement
brooks wildcarding or not and if not could simply use ifunit for their test.
brooks Third, make if_clone_lookup treat names like gif# as a wildcard
brooks request and set unit to -1 as appropriate. These changes break
brooks compatability with NetBSD slightly, but it's just a few lines to convert
brooks an existing NetBSD clone_create handler to this style and it could
brooks easily be handled with #ifdef's.
brooks Thoughts, comments, objections?
I like your idea.
I'm serving tunnel broker using DTCP (Dynamic Tunnel Configuration
Protocol) in our ISP. So, I'm grad if we have dynamic gif creation,
too.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
Brian Somers wrote: I went ahead and nuked the auto-creation and -D flag in favor of plumb and unplumb in the patch at: http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff This version includes a change to rc.network to plumb gif interfaces before calling gifcreate. This will still trip up users who build static gif tunnels from hosts with dynamic addresses since they can't run gifconfig yet, but we don't really have any means of supporting that in the rc files yet anyway. -- Brooks This looks good to me. I've cc'd freebsd-arch to see if anyone else wants to comment. If there are no objections, I'll test commit it in about a week. Personally, I'd prefer create/destroy instead of plumb/unplumb. The Solaris plumb command is for doing 'STREAMS plumbing' - ie: connecting all the streams pipes and modules together. Creating/deleting interfaces on BSD systems IMHO has nothing in common with that concept. We are creating/destroying interfaces, not connecting/disconnecting streams nodes (plumbing). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
On Mon, Jun 11, 2001 at 08:27:37AM -0700, Peter Wemm wrote:
Personally, I'd prefer create/destroy instead of plumb/unplumb. The Solaris
plumb command is for doing 'STREAMS plumbing' - ie: connecting all the
streams pipes and modules together. Creating/deleting interfaces on
BSD systems IMHO has nothing in common with that concept. We are
creating/destroying interfaces, not connecting/disconnecting streams
nodes (plumbing).
I've made create/destory the default names with plumb and unplumb
standing in as SysV compatability parameters because that seems to be
the ifconfig way. The diff at:
http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff
has been updated. I'm still thinking about adopting the NetBSD
SIOIF{CREATE,DESTORY} interface.
-- Brooks
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
PGP signature
Re: cloning network interfaces
On Mon, 11 Jun 2001, Brooks Davis wrote:
On Mon, Jun 11, 2001 at 08:27:37AM -0700, Peter Wemm wrote:
Personally, I'd prefer create/destroy instead of plumb/unplumb. The Solaris
plumb command is for doing 'STREAMS plumbing' - ie: connecting all the
streams pipes and modules together. Creating/deleting interfaces on
BSD systems IMHO has nothing in common with that concept. We are
creating/destroying interfaces, not connecting/disconnecting streams
nodes (plumbing).
I've made create/destory the default names with plumb and unplumb
standing in as SysV compatability parameters because that seems to be
the ifconfig way. The diff at:
http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff
has been updated. I'm still thinking about adopting the NetBSD
SIOIF{CREATE,DESTORY} interface.
An advantage to also supporting the ioctl interface is that it permits
interface cloning to be used on systems where devfs is not used, or where
there are parts of the system where devfs is unavailable (i.e., various
forms of chroots). I think devfs is cool and all, but given the existance
of fairly sensical non-devfs ways to do things, I'm tempted suggest
supporting them also.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
On Mon, Jun 11, 2001 at 02:40:54PM -0400, Robert Watson wrote: An advantage to also supporting the ioctl interface is that it permits interface cloning to be used on systems where devfs is not used, or where there are parts of the system where devfs is unavailable (i.e., various forms of chroots). I think devfs is cool and all, but given the existance of fairly sensical non-devfs ways to do things, I'm tempted suggest supporting them also. Actually, the currently implemented method doesn't required devfs. It's just somewhat easier to use in the devfs case because it doesn't require a mknod then. I think there are enough good reasons for following the NetBSD example that's I'll probalby do it. I'm currently trying to figure out how they implemented it. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: cloning network interfaces
In message [EMAIL PROTECTED], Robe
rt Watson writes:
http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff
has been updated. I'm still thinking about adopting the NetBSD
SIOIF{CREATE,DESTORY} interface.
An advantage to also supporting the ioctl interface is that it permits
interface cloning to be used on systems where devfs is not used, or where
there are parts of the system where devfs is unavailable (i.e., various
forms of chroots). I think devfs is cool and all, but given the existance
of fairly sensical non-devfs ways to do things, I'm tempted suggest
supporting them also.
As I already said: a device with no other precense in /dev has only
quickdirty reasons for using DEVFS cloning.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
On Sun, Jun 10, 2001 at 11:29:07PM +0900, Hajimu UMEMOTO wrote: I think it is not BSD network way. Recent NetBSD has network interface cloning. It uses SIOCIFCREATE and SIOCIFDESTROY. It may good to port it to FreeBSD. I've looked it over and I generally like it. There is one problem though. That's the requirement that you use static units. The problem with this is that it forces you to implement free unit scanning in userland if you just want to create a unit and don't care what it is. If you have to do this, and things are being changed at any kind of significant rate, you have race condition between scanning the interface list for a free unit and trying to allocate it. This race can theoreticaly lead to starvation. My proposed solution is threefold. First, change the ifc_create pointer's type to: int (*ifc_create)(struct if_clone *, int *); so you can return a unit if the caller requests a wildcard unit (by passing -1). Second, move unit management in to the driver rather then just using ifunit in if_clone_create. Drivers could choose to implement wildcarding or not and if not could simply use ifunit for their test. Third, make if_clone_lookup treat names like gif# as a wildcard request and set unit to -1 as appropriate. These changes break compatability with NetBSD slightly, but it's just a few lines to convert an existing NetBSD clone_create handler to this style and it could easily be handled with #ifdef's. Thoughts, comments, objections? -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: cloning network interfaces
I went ahead and nuked the auto-creation and -D flag in favor of plumb and unplumb in the patch at: http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff This version includes a change to rc.network to plumb gif interfaces before calling gifcreate. This will still trip up users who build static gif tunnels from hosts with dynamic addresses since they can't run gifconfig yet, but we don't really have any means of supporting that in the rc files yet anyway. -- Brooks This looks good to me. I've cc'd freebsd-arch to see if anyone else wants to comment. If there are no objections, I'll test commit it in about a week. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
Hi,
On Fri, 8 Jun 2001 19:19:04 -0700
Brooks Davis [EMAIL PROTECTED] said:
brooks Following Brian's suggestion, I've modified gif to create a /dev/if_gif
brooks device with is controlled by the IOCIFMANAGE ioctl which allows creation
brooks and deletion of specific devices and creation of wildcard devices. I've
brooks hacked ifconfig to support this in a general manner. If you know which
brooks one you want to use you can do something like
I think it is not BSD network way. Recent NetBSD has network
interface cloning. It uses SIOCIFCREATE and SIOCIFDESTROY. It may
good to port it to FreeBSD.
brooks ifconfig gif783 10.0.0.1 10.0.0.2
brooks # gifconfig has to come second because I didn't add creation support to
brooks # it because I want to kill it off in favor of ifconfig tsrc and
brooks # tdst parameters like Solaris uses.
brooks gifconfig gif783 blah
brooks or if you don't care which one you use you can do
brooks newgif=`ifconfig gif#`
brooks gifconfig ${newgif} blah
brooks ifconfig ${newgif} 10.0.0.1 10.0.0.2
brooks You can also delete interfaces:
brooks ifconfig -D gif783
NetBSD's ifconfig has `create' and `destroy' keyword for it.
You can create gif interface by
ifconfig gif0 create
or
ifconfig gif0 create tunnel 10.0.0.1 10.0.2.2
To destroy gif interface:
ifconfig gif0 destroy
BTW, gifconfig will be obsoleted soon as KAME and other BSDs did.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
On Sun, Jun 10, 2001 at 11:29:07PM +0900, Hajimu UMEMOTO wrote: I think it is not BSD network way. Recent NetBSD has network interface cloning. It uses SIOCIFCREATE and SIOCIFDESTROY. It may good to port it to FreeBSD. I'll take a look at it. I'm not convinced the /dev/if_gif way is wrong. Creation and destruction is an out of band operation and using socket interface IOCTLS seems to change their semantics significantly. Without devfs, I'd probably agree because you'd have to add and remove the /dev/if_gif device manualy, but with it, device creation is basicaly free (ok, for now it takes a major, but not for long.) Anyway, I'll consider it, but I don't promise to adopt it. NetBSD's ifconfig has `create' and `destroy' keyword for it. You can create gif interface by ifconfig gif0 create or ifconfig gif0 create tunnel 10.0.0.1 10.0.2.2 To destroy gif interface: ifconfig gif0 destroy I've moved to `plumb' and `umplumb' like solaris. I'll definatly add `create' and `destroy'. BTW, gifconfig will be obsoleted soon as KAME and other BSDs did. Good, it doesn't make much sense. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: cloning network interfaces
Ok, I've got the quick and dirty way working for testing (a nine line clone handler works great for that), but I think Brian's suggestion is probably best for a real solution especialy since it's rather easier to check for permissions before allowing creation this way. My current patch lets joe user create 2^15 gif devices by doing ls /dev/gif### 2^15 times because I didn't have a proc structure handy. The other advantage is that it should be fairly easy to backport to -stable which is where the project I'm working on this for is currently being developed. I think I'll add a to ifconfig function styled after ifmaybeload() that trys to create interfaces if the user trys to do something with them. I'm still thinking about the right way to handle creation of new, free devices, perhaps a syntax like: ifconfig gif# where ifconfig returns the interface name the way mdconfig does when you don't specify a unit. If we decied that interfaces that want to grow this way will have a /dev/if_name device that accepts the appropriate ioctl(s), that should be fairly easy to implement so it works in all cases without further hacks to ifconfig. I think it'd be better to use the solaris ``plumb'' keyword. I can't recall how it works (something like ``ifconfig gif0 plumb'' - I haven't got a Solaris machine handy here), but it seemed cleaner, making it more obvious what's being done. An ``unplumb'' keyword may be appropriate for doing the removal. -- Brooks -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
On Sat, Jun 09, 2001 at 09:24:22PM +0100, Brian Somers wrote: I think it'd be better to use the solaris ``plumb'' keyword. I can't recall how it works (something like ``ifconfig gif0 plumb'' - I haven't got a Solaris machine handy here), but it seemed cleaner, making it more obvious what's being done. An ``unplumb'' keyword may be appropriate for doing the removal. That's how it works. I've though about adding (un)plumb functions, but that gets a bit weird. With the current way ifconfig parses options would require that you peak at the argument list early because you need to create the device before arguments are processed. Also, given the way the FreeBSD rc system works you have to support commands like: ifconfig gif0 plumb inet 10.0.0.1 10.0.0.2 tsrc 192.168.1.6 tdst 192.168.1.7 because you only get one shot at each device[0]. In -stable I think I'd like to leave the current create behavior where devices are created if you try to use them and perhaps emit a warning suggesting using plumb to avoid breaking configs. In 5.0 I'd be reasionably happy to force plumbing of interfaces if there's come concensus that it's the right way to go. Alternativly, we could hack the rc system to try plumbing all interfaces before they are used. Any opinions on this? -- Brooks [0] This is actually a serious problem with wireless interfaces today because you can't write: ifconfig wi0 ssid XXX wepmode on wepkey 1:12345 DHCP which is exactly what you want to do on most home networks. IMO following the Solaris example of teaching ifconfig about dhcp is the right way to go here. Perhaps by allowing plugable external parameters to keep it general. -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: cloning network interfaces
On Sat, Jun 09, 2001 at 07:02:14PM -0700, Brooks Davis wrote: On Sat, Jun 09, 2001 at 09:24:22PM +0100, Brian Somers wrote: I think it'd be better to use the solaris ``plumb'' keyword. I can't recall how it works (something like ``ifconfig gif0 plumb'' - I haven't got a Solaris machine handy here), but it seemed cleaner, making it more obvious what's being done. An ``unplumb'' keyword may be appropriate for doing the removal. That's how it works. I've though about adding (un)plumb functions, but that gets a bit weird. With the current way ifconfig parses options would require that you peak at the argument list early because you need to create the device before arguments are processed. Also, given the way the FreeBSD rc system works you have to support commands like: ifconfig gif0 plumb inet 10.0.0.1 10.0.0.2 tsrc 192.168.1.6 tdst 192.168.1.7 because you only get one shot at each device[0]. In -stable I think I'd like to leave the current create behavior where devices are created if you try to use them and perhaps emit a warning suggesting using plumb to avoid breaking configs. In 5.0 I'd be reasionably happy to force plumbing of interfaces if there's come concensus that it's the right way to go. Alternativly, we could hack the rc system to try plumbing all interfaces before they are used. Any opinions on this? I went ahead and nuked the auto-creation and -D flag in favor of plumb and unplumb in the patch at: http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff This version includes a change to rc.network to plumb gif interfaces before calling gifcreate. This will still trip up users who build static gif tunnels from hosts with dynamic addresses since they can't run gifconfig yet, but we don't really have any means of supporting that in the rc files yet anyway. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: cloning network interfaces
Following Brian's suggestion, I've modified gif to create a /dev/if_gif
device with is controlled by the IOCIFMANAGE ioctl which allows creation
and deletion of specific devices and creation of wildcard devices. I've
hacked ifconfig to support this in a general manner. If you know which
one you want to use you can do something like
ifconfig gif783 10.0.0.1 10.0.0.2
# gifconfig has to come second because I didn't add creation support to
# it because I want to kill it off in favor of ifconfig tsrc and
# tdst parameters like Solaris uses.
gifconfig gif783 blah
or if you don't care which one you use you can do
newgif=`ifconfig gif#`
gifconfig ${newgif} blah
ifconfig ${newgif} 10.0.0.1 10.0.0.2
You can also delete interfaces:
ifconfig -D gif783
Additionaly, I removed all the annoying refrences to gif.h and NGIF, and
moved things around so gif can be loaded and unloaded as a module.
A copy of the diff as avaiable at the URL below and I'm submitting a PR
titled [PATCH] make gif fully dynamic.
http://www.one-eyed-alien.net/~brooks/FreeBSD/gif.diff
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
PGP signature
Re: cloning network interfaces
In message [EMAIL PROTECTED], Brooks Davis writes: With network devices that are also normal devices the way tun is, you do this by just implementing a dev_clone event handler so when the user attempts to open a non-existent instance it's created. The problem with gif is that there's no device in /dev to open. Since most network devices at attached to hardware this usually doesn't matter, but in this case it does. [...] How would this work anyway? Comments, thoughts, ideas? The quick and dirty way: Make a clone handler despite the fact that there is no /dev entry needed. You don't actually have to create a dev entry in the clone handler, you could just create the gif_interface. Applications would then: stat(/dev/gif345) /* Ignore error */ system(ifconfig gif345 bla bla bla); The slower but less dirty: Make a sysctl which returns an integer which is the next free gif device. The really slow and very dirty: Implement cloning in ifconfig. Maybe a reasonable alternative would be to have a /dev/if_gif device with ioctls for creating and destroying interfaces. ifconfig(8) could be taught to create (and maybe even to delete) them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cloning network interfaces
On Thu, Jun 07, 2001 at 12:19:53PM +0100, Brian Somers wrote: The quick and dirty way: Make a clone handler despite the fact that there is no /dev entry needed. You don't actually have to create a dev entry in the clone handler, you could just create the gif_interface. Applications would then: stat(/dev/gif345) /* Ignore error */ system(ifconfig gif345 bla bla bla); The slower but less dirty: Make a sysctl which returns an integer which is the next free gif device. The really slow and very dirty: Implement cloning in ifconfig. Maybe a reasonable alternative would be to have a /dev/if_gif device with ioctls for creating and destroying interfaces. ifconfig(8) could be taught to create (and maybe even to delete) them. Ok, I've got the quick and dirty way working for testing (a nine line clone handler works great for that), but I think Brian's suggestion is probably best for a real solution especialy since it's rather easier to check for permissions before allowing creation this way. My current patch lets joe user create 2^15 gif devices by doing ls /dev/gif### 2^15 times because I didn't have a proc structure handy. The other advantage is that it should be fairly easy to backport to -stable which is where the project I'm working on this for is currently being developed. I think I'll add a to ifconfig function styled after ifmaybeload() that trys to create interfaces if the user trys to do something with them. I'm still thinking about the right way to handle creation of new, free devices, perhaps a syntax like: ifconfig gif# where ifconfig returns the interface name the way mdconfig does when you don't specify a unit. If we decied that interfaces that want to grow this way will have a /dev/if_name device that accepts the appropriate ioctl(s), that should be fairly easy to implement so it works in all cases without further hacks to ifconfig. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
