Re: dev.* analogue for interfaces

John-Mark Gurney <jmg@xxxxxxxxxxxx> writes:
My concern is that slowly adding them for each interface type could
create some conflicts in both naming and location...

each interface type? this would be done in if_attach() / if_detach(),
everything is taken care of centrally for all interfaces.

Are the interface sysctl nodes going to be the same/mirrored for hardware
devices? Does dev.msk.0 get duplicated in the interface area?

No, there's if.* for interface stuff and dev.* for hardware stuff. Some
nodes might move from one tree to the other, but I suspect that most
won't. Like I said, some interfaces already do this "manually" under
net.*.

or does it
have to decide to put ethernet interface related items in the if sysctl
node, and other hardware related (hi/low water marks for DMA) in the
seperate tree? How does someone know where to look if they are in
different locations for the same device?

Not all interfaces are devices. That is the whole point...

We should probably create a newbus tree node off the nexus for psuedo
devices that are not backed by hardware, and put all of these style
devices under them...

Uh, no.

Devices that aren't backed by hardware are still devices, they still
have a device_t, and they still have dev.* nodes; nexus is not backed by
hardware, for instance, it's just a convenient top-level device that
serves as parent for all other devices.

Basically, there is a dev.* node for every device_t in the system.

I want to have an if.* node for every struct ifnet.

This will help enforce non-conflicting names,

I don't see why you're so hung up on conflicting names. It's a non-
issue. Every interface has a unique name.

DES
--
Dag-Erling Smørgrav - des@xxxxxx
_______________________________________________
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

  • Re: Newbie Modelling Interface Question
    ... A client's access to this subsystem is ... interface has a message identifier and a by-value data packet. ... The client then has a pointer to each interface. ... For example, in a hardware interface, clients usually want to manipulate ...
    (comp.object)
  • Re: OpenGL-based framebuffer concepts
    ... Agreed that kernel should only deal with necessary tasks as minimum as ... Designing the interface inevitably involves clear understanding of the ... hardware capabilities and closed hardware spec is an obvious obstacle. ... Open Graphics card would be a great thing ...
    (Linux-Kernel)
  • Re: Cubase SX or Pro-Tools M-Powered?
    ... electronic type composers, MIDI editing, sound stretching etc while ... besides a history lesson and marketing targets, they all employ a 'hyper-tape' type setup unifying audio, midi, and automation in one interface, but obviously going beyond the abilities of tape. ... ProTools would restrict your choice of hardware. ...
    (rec.audio.pro)
  • Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
    ... The interface should be used ... > to map the hardware, there will always be opportunity for abuse. ... any faster than it would to invalidating a memory region. ... Instead it is allowed to block on such a request and only guarantees ...
    (Linux-Kernel)
  • Funded Ph.D. Position - Formalising the Hardware/Software Interface, TCD, Ireland
    ... Formalising the Interface between Software and Hardware ... Software Systems Laboratory, ... hardware and software, with particular emphasis on Flash Memory ...
    (comp.theory)