Re: dev.* analogue for interfaces

Dag-Erling Smørgrav wrote:
Four years ago, I created the dev.* sysctl tree for device drivers.
Every time a device is registered, a sysctl context is automatically
created, and a node is created under dev (e.g. dev.cpu.0), with some
standardized nodes under it (%driver, %parent, %desc etc.) plus any node
the driver - or even another driver - wants to add.

However, not everything in Unix is a device. Specifically, network
interfaces aren't.

Some network interfaces are also devices, so they have a sysctl node in
dev.*:

% sysctl dev.msk
dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x02
dev.msk.0.%driver: msk
dev.msk.0.%parent: mskc0

Others don't: bridge, faith, lo, pflog, vlan etc.

What I propose is to add a similar sysctl tree for interfaces. It would
look a little different. For instance, some interfaces (bridge, vlan)
have parents or children, but most don't.

Just as it is for devices, creation and destruction of the interface's
sysctl node and context would be hidden inside if_{attach,detach}() and
completely transparent to the driver, and there will be an API that
drivers can use if they want to add their own nodes.

Since interfaces don't all have parents, the API will include a function
to specify one for those that do.

This is *not* intended to replace ifconfig; it is intended for infor-
mation which isn't available through ifconfig and which it wouldn't be
natural to place there. For instance, every wlan interface already has
a sysctl tree under net.wlan.

Drivers that already have sysctl nodes will require less code to create
them, and no code at all to destroy them, since if_detach() will take
care of that (all nodes in the interface's context are automatically
destroyed when the context is destroyed).

I'm unsure whether this should go under net.if, or just if. I think I
prefer the latter.

I'm open to objections and suggestions...

the usual things apply:

a) If you do the work most people would go along. :-)

b) being able to compile it without the bloat might be a good idea for
embeded systems.



DES

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

Relevant Pages

  • dev.* analogue for interfaces
    ... I created the dev.* sysctl tree for device drivers. ... Every time a device is registered, a sysctl context is automatically ... the driver - or even another driver - wants to add. ... interfaces aren't. ...
    (freebsd-arch)
  • Re: if_ath breaks s3 suspend/resume [Was: ACPI S3 wakeup problem (beeeeeeeeep)]
    ... Now with this sysctl enabled I hear a continuing beep, but the hard drive stays powered down, also the LCD keeps unlit. ... but sometimes I get a hang during bootup shortly after ath0 is brought up. ... For the hang I'm not sure how to reproduce it. ... not a driver problem. ...
    (freebsd-current)
  • [PATCH] I2C: Kill i2c_client.id (5/5)
    ... * [Sysctl] All sysctl stuff is of course gone (defines, ... existing 2.6 driver for details. ... sysfs file creation. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: API to turn off the display
    ... > I wrote a driver that handles what John told. ... Output from 'sysctl hw.acpi.video' after loading the module: ... When switching to sleep state S1 the display is not ...
    (freebsd-current)
  • Re: API to turn off the display
    ... > I wrote a driver that handles what John told. ... > This driver uses ACPI video extension to control display switching and ... littleguy# sysctl hw.acpi.video.lcd0.active=0 ... out was active yielded the same results as the lcd, ...
    (freebsd-current)