[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AltQ



On Tue, 1 Feb 2000, Thierry Deval wrote:

 | Couldn't we use the same majors across platforms ? Do they diverge that much ?
 | 

if you look at, say, /usr/src/sys/arch/sparc/sparc/conf.c, major numbers
up to 123 are allocated.  Under /usr/src/sys/arch/i386/i386/conf.c, it is up
to 63.

Major numbers not portable (which is why there's a separate /dev/MAKEDEV for
each architecture) simply because they are for devices and some devices may
exist on some platforms and not others.

 | > Also, if the architecture has a special high resolution
 | > timer (like the pentium's TSC timer) then support should be added in
 | > altq/altq_subr.c.
 | 
 | Wow, low-level coding... What archs do have such features (do we consider
 | variants like 68360 <-> m68k; of course they are not supported) ?
 | Let's go to the datasheets ...
 | 

Well, it will use microtime if you don't do this.  Unless there is code to
support the alternative timer feature (such as, the i386 arch has code to
support TSC) then it needs to be done (could be taken from netbsd if they
have it and we dont for instance)

The RTMX real-time code includes a high resolution kernel timer (according to
www.rtmx.com).. When the RTMX real-time code is merged into current, this may
be an alternative.

The point of all this is for the developers to accept the commit of ALTQ into
the tree.  This will not happen until ALTQ is modified to support all
architectures, and either a vast majority of network drivers are modified to
work with ALTQ or ALTQ is redesigned to work in a different manner (Which I
don't think will happen at all ;)

So, the real question is, does anyone want to modify network drivers?? The
modifications became more complex between altq-2.0 and altq-2.1 and are not
documented in the altq how-to-modify-drivers.txt.  (I don't want to do this 
if someone else does ;)

Of course if people using other architectures are interested in ALTQ then
please get it together!!

-chris