Adding bootverbose
Jaromír Doleček
do people have some strong objections against adding boot verbose
flag ? Would make porting FreeBSD code little bit easier and
generally seems like good idea - could enable to compile with
all the debugging messages compiled in, yet still print all the
stuff only when needed.
Jaromir
Matthew Jacob wrote on source-...@netbsd.org (shortened):
> What I really wanted was a 'boot verbose'- which isn't available in NetBSD.
> The whole message stuff in this driver is about to get nuked in a few
> weeks anyway, at which point in time, the cheezy defines will go away.
>
> On Wed, 5 Jul 2000, John Hawkinson wrote:
> > | ----------------------------
> > | revision 1.53
> > | date: 2000/06/03 22:44:43; author: fair; state: Exp; lines: +3 -3
> > | Change the debug level from 1 to 3 for "skipping target" diagnostic
> > | which spews unreasonably for a Qlogic SCSI-2 narrow controller, which
> > | does not have ID's above 7.
> > | ----------------------------
> > | revision 1.54
> > | date: 2000/07/05 22:20:51; author: mjacob; state: Exp; lines: +476 -521
> > | Back out previous commit- the author is incorrect. There is no 'narrow'
> > | Qlogic controller driven by this chipset. If they don't want the verbosity,
> > | don't compile a DIAGNOSTIC kernel.
> >
> > This does not follow.
> >
> > "DIAGNOSTIC" is for "cheap kernel consistency checks". It is not for
> > debugging messages. DIAGNOSTIC is part of the GENERIC kernel for most
> > architectures.
> >
> > This whole section of code, isp_netbsd.h:
> >
> > 107 #if defined(SCSIDEBUG)
> > 108 #define DFLT_DBLEVEL 3
> > 109 #define CFGPRINTF printf
> > 110 #elif defined(DEBUG)
> > 111 #define DFLT_DBLEVEL 2
> > 112 #define CFGPRINTF printf
> > 113 #elif defined(DIAGNOSTIC)
> > 114 #define DFLT_DBLEVEL 1
> > 115 #define CFGPRINTF printf
> > 116 #else
> > 117 #define DFLT_DBLEVEL 0
> > 118 #define CFGPRINTF if (0) printf
> > 119 #endif
> >
> > is bogus. DIAGNOSTIC should not cause increased debugging printfs.
> >
> > To my mind, fair's code was better than the current state or the state
> > prior to it. Neither was correct, though.
> >
> > Further, most drivers do this sort of thing with a driver-specific macro,
> > such as ISPDEBUG_VALUE or ISPDEBUG or somesuch. This behavior
> > of changing verbosity based on other unrelated items
> > (e.g. DEBUG and DIAGNOSTIC) is non-intuitive and can produce
> > nasty changes in behavior when trying to debug other subsytems.
> >
> > Can we please axe it, or at least make the DIAGNOSTIC level the same
> > as that without it?
> >
> > --jhawk
> >
--
Jaromir Dolecek <jdol...@NetBSD.org> http://www.ics.muni.cz/~dolecek/
@@@@ Wanna a real operating system ? Go and get NetBSD, damn! @@@@
Matthew Jacob
> BTW,
>
> do people have some strong objections against adding boot verbose
> flag ? Would make porting FreeBSD code little bit easier and
> generally seems like good idea - could enable to compile with
> all the debugging messages compiled in, yet still print all the
> stuff only when needed.
>
I find it useful- there is also the same thing under Solaris.
The idea here is to reduce the noise (a good thing) but have
the diagnostic tools available (w/o a recompile) to write
down messages that can go into mail or into a PR.
Jaromír Doleček
> The idea here is to reduce the noise (a good thing) but have
> the diagnostic tools available (w/o a recompile) to write
> down messages that can go into mail or into a PR.
Hmm, I've got some time to play with this and made necessary changes
to support the verbose booting. I haven't tested it on all archs
yet :-/ nor I am sure it really DTRT for all archs (for example the change
for arm32).
Couple of issues: amigappc,arm26,mac68k don't seem to pass/recognize
any boot flags. Is the info passed other way ? (comment in mac68k
code points to Booter and env. variable BOOTHOWTO - what is that ?).
evbsh3,mmeye,sh3,news68k,newsmips,sgimips,vax don't seem to
get the boothowto eiher, seems like the only way to set the boot flags
is reboot(2), whose flags are stored in non-volatile place. Or do
I just overlook something ?
hpcmips already had something like this, so I changed it's htpcmips_verbose
with bootverbose.
The flag parsing code is very similar on many archs (there are like
2-3 different ways of doing it, probably depending on where the
author cut&pasted the code :) ), it would be probably good to clean
it up and move into some more central place.
Note I haven't changed reboot(1) to make it possible to pass the verbose
flag, nor did I changed any MD code to store the flag in cpu_reboot() yet.
That should probably be done.
The patch is available at:
http://www.ics.muni.cz/~dolecek/NetBSD/bootverbose.diff
It's size is about 18KB.
Jaromir
Ben Harris
>Couple of issues: amigappc,arm26,mac68k don't seem to pass/recognize
>any boot flags. Is the info passed other way ?
arm26 passes a binary structure from the bootloader to the kernel. Look in
sys/arch/arm26/include/boot.h.
>evbsh3,mmeye,sh3,news68k,newsmips,sgimips,vax don't seem to
>get the boothowto eiher, seems like the only way to set the boot flags
>is reboot(2), whose flags are stored in non-volatile place. Or do
>I just overlook something ?
Well, in sys/arch/vax/vax/subr.s, the VAX seems to get its boothowto from
R11 on old bootloaders:
movl r11,_boothowto # Howto boot (single etc...)
On later bootloaders, it's passed in the RPB (in rpb_bootr5) (see locore.c):
boothowto = prpb->rpb_bootr5;
--
Ben Harris
Portmaster, NetBSD/arm26
Ignatios Souvatzis
> Couple of issues: amigappc... don't seem to pass/recognize
> any boot flags. Is the info passed other way ?
Not yet. Soon, as some binary info similar, or completely different, from
amiga[68k].
Regards,
-is
Greywolf
# > BTW,
# >
# > do people have some strong objections against adding boot verbose
# > flag ? Would make porting FreeBSD code little bit easier and
# > generally seems like good idea - could enable to compile with
# > all the debugging messages compiled in, yet still print all the
# > stuff only when needed.
# >
#
# I find it useful- there is also the same thing under Solaris.
# The idea here is to reduce the noise (a good thing) but have
# the diagnostic tools available (w/o a recompile) to write
# down messages that can go into mail or into a PR.
I'm hoping that the "normal" method of booting isn't going to eliminate
all the stuff that we see that normally goes into dmesg, and that one
is required to boot verbose (-v) just to see one's configuration when
the machine comes up.
That's one more thing about Solaris that, IMNSHO, really sucks.
--*greywolf;
--
BSD: Multi-platform OS
Jaromír Doleček
> >any boot flags. Is the info passed other way ?
>
> sys/arch/arm26/include/boot.h.
Ah, I should have grepped for 'howto' even for arm26 :) Would following
be right for arm26 ?
Index: boot/BBBB,fd1
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/arm26/boot/BBBB,fd1,v
retrieving revision 1.1
diff -u -r1.1 BBBB,fd1
--- BBBB,fd1 2000/05/09 21:55:57 1.1
+++ BBBB,fd1 2000/07/06 15:53:46
@@ -68,6 +68,7 @@
WHEN "a" : howto% = howto% OR &01 : REM RB_ASKNAME
WHEN "s" : howto% = howto% OR &02 : REM RB_SINGLE
WHEN "d" : howto% = howto% OR &40 : REM RB_KDB
+ WHEN "v" : howto% = howto% OR &1000 : REM RB_VERBOSE
WHEN " ", "" : done% = TRUE
OTHERWISE : ERROR EXT 0, "Bad option: " + LEFT$(A$, 1)
ENDCASE
> Well, in sys/arch/vax/vax/subr.s, the VAX seems to get its boothowto from
> R11 on old bootloaders:
>
> movl r11,_boothowto # Howto boot (single etc...)
>
> On later bootloaders, it's passed in the RPB (in rpb_bootr5) (see locore.c):
>
> boothowto = prpb->rpb_bootr5;
Well, I did found this, just couldn't find where either r11 or prpb->rpb_bootr5
is initialized, i.e. if there is way for user to specify boot flags
similar way to i386's : boot FILE -s
Okay, I'll look a bit further :)
Ben Harris
> Ben Harris wrote:
> > In article <200007061206...@saruman.ics.muni.cz> you write:
> > >Couple of issues: amigappc,arm26,mac68k don't seem to pass/recognize
> > >any boot flags. Is the info passed other way ?
> >
> > arm26 passes a binary structure from the bootloader to the kernel. Look in
> > sys/arch/arm26/include/boot.h.
>
> Ah, I should have grepped for 'howto' even for arm26 :) Would following
> be right for arm26 ?
[snip]
Seems fine to me, yes.
> > Well, in sys/arch/vax/vax/subr.s, the VAX seems to get its boothowto from
> > R11 on old bootloaders:
> >
> > movl r11,_boothowto # Howto boot (single etc...)
> >
> > On later bootloaders, it's passed in the RPB (in rpb_bootr5) (see locore.c):
> >
> > boothowto = prpb->rpb_bootr5;
>
> Well, I did found this, just couldn't find where either r11 or prpb->rpb_bootr5
> is initialized, i.e. if there is way for user to specify boot flags
> similar way to i386's : boot FILE -s
> Okay, I'll look a bit further :)
Well, vax/boot/boot/boot.c sets bootr5 based on options it gets
interactively. vax/boot/xxboot/bootxx.c seems to initialise it from the
environment, presumably so you can type "B/3" at MicroVAX etc consoles.
--
Ben Harris <bj...@netbsd.org>
Portmaster, NetBSD/arm26 <URL:http://www.netbsd.org/Ports/arm26/>
Matthew Jacob
Hubert Feyrer
Question: as much as i'd love to have bootverbose available on install
disks (and only there): which size impact does that have? We're already
pretty low on space...
- Hubert
--
NetBSD - because Unix isn't just #include <linux.h>, i386, ILP32, ELF, ...!
Michael L. Hitch
> > Well, in sys/arch/vax/vax/subr.s, the VAX seems to get its boothowto from
> > R11 on old bootloaders:
> >
> > movl r11,_boothowto # Howto boot (single etc...)
> >
> > On later bootloaders, it's passed in the RPB (in rpb_bootr5) (see locore.c):
> >
> > boothowto = prpb->rpb_bootr5;
>
> Well, I did found this, just couldn't find where either r11 or prpb->rpb_bootr5
> is initialized, i.e. if there is way for user to specify boot flags
> similar way to i386's : boot FILE -s
The boot flags are set on the PROM monitor boot command, typically:
>>> boot/flags dka0
or
>>> boot/r5:flags dka0
[with a few other methods on some machines.]
The NetBSD boot loader also parses some flags and sets the rpb_bootr5
flags (see vax/boot/boot/boot.c), so the 'v' flag can be added there.
--
Michael L. Hitch mhi...@montana.edu
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA
Matthew Jacob
> Question: as much as i'd love to have bootverbose available on install
> disks (and only there): which size impact does that have? We're already
> pretty low on space...
Probably no more than is already there with current DEBUG kernels.
Why only on the install disks?
Hubert Feyrer
Because I(!)'ve needed it only on the install disks, which I use to play
with new machines. On machines that run NetBSD, I don't need to debug
the kernel. Usually.
Matthew Jacob
> > > Question: as much as i'd love to have bootverbose available on install
> > > disks (and only there): which size impact does that have? We're already
> > > pretty low on space...
> >
> > Probably no more than is already there with current DEBUG kernels.
> > Why only on the install disks?
>
> Because I(!)'ve needed it only on the install disks, which I use to play
> with new machines. On machines that run NetBSD, I don't need to debug
> the kernel. Usually.
Fair enough. However, over the last 23 years my first response to reported
problems are "can you build a debug kernel and reproduce the problem and send
me the output..." :-)
Matthew Jacob
> all the stuff that we see that normally goes into dmesg, and that one
> is required to boot verbose (-v) just to see one's configuration when
> the machine comes up.
Actually, let me finally answer this part of the email.
What we should have is something *like* prtconf that can print a device's h/w
infrastructure from userland. Then you don't need or want dmesg to boot
messages just to see what is attached and functioning.
And in the hotswap case (which I'm sure we'll all get more and more to like),
this is a far better tool than boot messages.
Manuel Bouyer
>
> Question: as much as i'd love to have bootverbose available on install
> disks (and only there): which size impact does that have? We're already
> pretty low on space...
It's hard to say ... For example all the IDE/ATAPI code already has DEBUG
messages compiled it, controlled by patchable variables.
-v could turn some of these on, without much size penalty.
--
Manuel Bouyer <bou...@antioche.eu.org>
--
Jaromír Doleček
>
> Question: as much as i'd love to have bootverbose available on install
> disks (and only there): which size impact does that have? We're already
> pretty low on space...
bootverbose is meant (AFAICS) for things, which would normally
appear, but is not interesting enough to be printed ALWAYS.
IMHO PCI interrupt routing fixup tables are good candidate
for beeing conditional on bootverbose.
e.g. debug messages could be only compiled in ifdef SUBSYS_DEBUG,
but only be printed if also bootverbose is true - this way
we can run with debug-enabled kernel and only boot with verbose
printing when needed (this is also easily sysctlable, if needed).
Lucio De Re
>
> On Thu, Jul 06, 2000 at 07:02:04PM +0200, Hubert Feyrer wrote:
> >
> > Question: as much as i'd love to have bootverbose available on install
> > disks (and only there): which size impact does that have? We're already
> > pretty low on space...
>
> messages compiled it, controlled by patchable variables.
> -v could turn some of these on, without much size penalty.
>
been raised) that one cannot include SCSI adapters (at least the Adaptec
ones I've been using) without including SCSIVERBOSE. There are some normal
SCSI diagnostics - I am too pressed for time to look now - that use the
SCSIVERBOSE infrastructure to print.
I think this was present up to and including 1.4.2, the last kernel I had
occasion to build.
Sorry to go a little off topic, but if I don't bring this up while my mind
has been freshly jolted, I never will.
Once I'm back home next week, I may well find the time to look deeper
into it, if the above isn't enough to identify and solve the problem.
++L
Robert Elz
From: Matthew Jacob <mja...@feral.com>
Message-ID: <Pine.BSF.4.10.100070...@beppo.feral.com>
| What we should have is something *like* prtconf that can print
| a device's h/w infrastructure from userland.
I agree, that would be nice, and certainly has its uses (for anyone
who ever decides to do that, bonus points for actually being able to
print the hardware section of a config(8) format file to match the
current running system).
But that and bootverbose are pretty much orthagonal. prtconf or
similar, will tell me what is there, what bootverbose ought to be
doing is telling me all that is not there, and why the kernel believes
that.
That is, if I know that I have some random card is plugged in (I
can see the thing...) why can't the kernel see it? Bootverbose (if
done properly) would tell me that - it would list all the devices probed,
and say why the driver gave up on finding that device.
I'm in two minds about it on install floppies - sure it would be
great to have, so when installing you'd know that your ethernet card
isn't being recognised because it is strapped to the wrong address,
and thus what to change to fix it. (Since clearly compiling a new
kernel isn't an option at this stage.) But it will make the kernel
bigger, and that might be just too much to take. Perhaps a "kernel
only" floppy image (with no embedded filesys) which would just boot,
then panic (no root, no init) - but would at least find all the
hardware that exists (and with a verbose boot, why other hw is ignored)
so those problems could be corrected when needed, then go back to
the regular install. It wants to be a kernel so it can be built
from the same sources (and config file) as the real install kernel,
so divergence doesn't cause the two to act differently.
kre
Bill Sommerfeld
- quiet (see pr kern/5155)
- normal (running about one or two lines per driver instance,
roughly equivalent to current behavior,
and the default default value)
- verbose (spewing more detail).
with boot flags to select each, and a default value specifiable in
boot blocks and/or kernel config file.
the rationale for "quiet" is simple:
certain embedded applications of netbsd might not want to throttle
kernel initialization based on how quickly they can spew out a 9600
baud serial console; others might not want to baffle users with the
spewage.
RB_QUIET, RB_VERBOSE, ...
- Bill
matthew green
i really like this. espcially the boot -p flag.
i think netbsd should go with this solution.
thanks chris.
Christopher Reid Palmer
[Chris Torek's BSD/OS verbosity example]
> i think netbsd should go with this solution.
I'm more your curious user type than your kernel hacker type, but I too
found the BSD/OS 4-level verbosity compelling and nice.
$0.02,
--
Chris
www.innerfireworks.com
Jonathan Stone
In message <Pine.LNX.4.21.00071...@dusk.bitstream.net>
>[Chris Torek's BSD/OS verbosity example]
>
>> i think netbsd should go with this solution.
>
>I'm more your curious user type than your kernel hacker type, but I too
>found the BSD/OS 4-level verbosity compelling and nice.
It looks great to me, too. Thanks to Chris for sharing the info.
I wish we could get it into NetBSD-1.5, even.
Jason R Thorpe
> It looks great to me, too. Thanks to Chris for sharing the info.
> I wish we could get it into NetBSD-1.5, even.
Way too many changes for 1.5.
--
-- Jason R. Thorpe <tho...@zembu.com>
Jonathan Stone
In message <2000071713...@dr-evil.z.zembu.com>Jason R Thorpe writes
>On Mon, Jul 17, 2000 at 12:53:21PM -0700, Jonathan Stone wrote:
>
> > It looks great to me, too. Thanks to Chris for sharing the info.
> > I wish we could get it into NetBSD-1.5, even.
>
>Way too many changes for 1.5.
Yeah, that's why I said "wish".
Jaromír Doleček
> Way too many changes for 1.5.
Sure, but the infrastructure can be there - most importatntly, all the
required additions to bootblocks on various archs to support
bootverbose & friends. I'd like to pull the changes up once I finish
it. The bootblock versioning changes need to go first, though :)
Brett Lymn
(sorry for the late reply - just saw this....)
According to Robert Elz:
>
> From: Matthew Jacob <mja...@feral.com>
> Message-ID: <Pine.BSF.4.10.100070...@beppo.feral.com>
>
> | What we should have is something *like* prtconf that can print
> | a device's h/w infrastructure from userland.
>
>I agree, that would be nice,
What, you mean like this:
[root@siren] prtconf
System is a i386 architecture on a Intel Pentium Pro (686-class)
with 100270080 bytes of physical memory, 96485376 bytes is
non-kernel memory
mainbus0
pnpbios0
pci0
pchb0 (device = 0, function = 0)
pcib0 (device = 1, function = 0)
isa0
com0 (irq = 4, port = 0x3f8)
com1 (irq = 3, port = 0x2f8)
pckbc0 (port = 0x60)
pckbd0
wskbd0
pmsi0
wsmouse0
pcppi0 (port = 0x61)
sysbeep0
isapnp0 (port = 0x279)
pcic0 (port = 0x3e0)
pcmcia0
pcmcia1
wi0 (port = 0x400, function = 1024)
sb0 (irq = 5, port = 0x220, drq = 1)
audio0
npx0 (port = 0xf0)
fdc0 (irq = 6, port = 0x3f0, drq = 2)
fd0 (drive = 0)
pciide0 (device = 1, function = 1)
atapibus0
cd1 (drive = 0)
de0 (device = 9, function = 0)
vga1 (device = 10, function = 0)
wsdisplay0
ahc0 (device = 13, function = 0)
scsibus0
sd0 (lun = 0)
cd0 (lun = 0)
[root@siren] uname -a
NetBSD siren 1.5_ALPHA NetBSD 1.5_ALPHA (SIREN) #24: Sat Jul 22
21:24:04 CST 2000 toor@siren:/usr/src/sys/arch/i386/compile/SIREN
i386
Most of the above is done by walking the in-kernel device tree, I am
forced to parse dmesg output to get the locators. My current version
will look for /var/run/dmesg.boot first and use it if it exists,
falling back to dmesg as a last resort.
> and certainly has its uses (for anyone
>who ever decides to do that, bonus points for actually being able to
>print the hardware section of a config(8) format file to match the
>current running system).
>
This is being struggled with - well, something that will build the
_whole_ config file for you.
Hmmm maybe it is time to prod core about putting prtconf into the
tree....
--
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================
Matthew Jacob
This is all pretty good as a start, but you *can'* use dmesg. Something else
has to be used. You also have to decide which is more important- spitting out
a config file (logical hierarchy) or printing out the device tree (hardware
hierarchy + pseudo device list).
Brett Lymn
>
>This is all pretty good as a start, but you *can'* use dmesg. Something else
>has to be used.
AFAIK the kernel does not store the locators anywhere - they are
printed out by the driver but that is it. _If_ the locators were
stored in kernel (ala the locator names) then I would happily use
them. I consider parsing dmesg output an ugly hack at best.
> You also have to decide which is more important- spitting out
>a config file (logical hierarchy) or printing out the device tree (hardware
>hierarchy + pseudo device list).
>
No, I disagree. The routines in prtconf that gather the data about
the devices can be shared with another tool that emits a config file,
if you think about it the data is the same it is just the presentation
that varies.
Matthew Jacob
> According to Matthew Jacob:
> >
> >This is all pretty good as a start, but you *can'* use dmesg. Something else
> >has to be used.
>
> AFAIK the kernel does not store the locators anywhere - they are
> printed out by the driver but that is it. _If_ the locators were
> stored in kernel (ala the locator names) then I would happily use
> them. I consider parsing dmesg output an ugly hack at best.
Yes- but maybe the locator info should be retained somewhere?
>
> > You also have to decide which is more important- spitting out
> >a config file (logical hierarchy) or printing out the device tree (hardware
> >hierarchy + pseudo device list).
> >
>
> No, I disagree. The routines in prtconf that gather the data about
> the devices can be shared with another tool that emits a config file,
> if you think about it the data is the same it is just the presentation
> that varies.
Hmm- yup. You're right. Too little sleep on my part. I think what I meant is
how you can reconcile a hardware tree (as gathered from incomplete
self-identifying h/w- OBP trees or PCI bussses, etc..) with a locator based
tree (which just tells you the attached driver hierarchy).
It may not be important to do so- but it would be nice also.
Brett Lymn
>
>Yes- but maybe the locator info should be retained somewhere?
>
I agree, every other time I have tried to suggest this it has fallen
on deaf ears. I would suggest that an array of ints, the same number
as there are entries in locname - the driver fills in the ints with
the correct locator values (sets the unused ones to -1???). It would
make things soooo much easier.
>
>Hmm- yup. You're right. Too little sleep on my part. I think what I meant is
>how you can reconcile a hardware tree (as gathered from incomplete
>self-identifying h/w- OBP trees or PCI bussses, etc..) with a locator based
>tree (which just tells you the attached driver hierarchy).
>
Mmmm not sure - I have not dealt with OBP at this level. Do you get
any addressing info back at all?
Matthew Jacob
> >Yes- but maybe the locator info should be retained somewhere?
> >
>
> I agree, every other time I have tried to suggest this it has fallen
> on deaf ears. I would suggest that an array of ints, the same number
> as there are entries in locname - the driver fills in the ints with
> the correct locator values (sets the unused ones to -1???). It would
> make things soooo much easier.
>
> >
> >Hmm- yup. You're right. Too little sleep on my part. I think what I meant is
> >how you can reconcile a hardware tree (as gathered from incomplete
> >self-identifying h/w- OBP trees or PCI bussses, etc..) with a locator based
> >tree (which just tells you the attached driver hierarchy).
> >
>
> Mmmm not sure - I have not dealt with OBP at this level. Do you get
> any addressing info back at all?
The Open Boot PROM has compete address info for all h/w.
Jason R Thorpe
> AFAIK the kernel does not store the locators anywhere - they are
> printed out by the driver but that is it. _If_ the locators were
> stored in kernel (ala the locator names) then I would happily use
> them. I consider parsing dmesg output an ugly hack at best.
Locators are difficult to store when you consider cloned devices. The
locator is "-1" :-).
I suppose the device structure could be changed to get an
"int *dv_loc" that is allocated when the device is attached
and filled in by the parent once the child has finished attaching
(that's the only way to fill in the correct locators).
Brett Lymn
>
>Locators are difficult to store when you consider cloned devices. The
>locator is "-1" :-).
>
Yes, sorta knew about that from my previous investigations :-)
>I suppose the device structure could be changed to get an
>"int *dv_loc" that is allocated when the device is attached
>and filled in by the parent once the child has finished attaching
>(that's the only way to fill in the correct locators).
>
Funny you should say that, this was exactly what I was thinking during
my walk from the train to work. The only proviso I would have is to
make the number of int's in dv_loc be the same as the number of
entries in locname, this way the tool surfing the structures does not
need to know what locators are relevant to the device - something that
is very device specific.
Jason R Thorpe
> Funny you should say that, this was exactly what I was thinking during
> my walk from the train to work. The only proviso I would have is to
> make the number of int's in dv_loc be the same as the number of
> entries in locname, this way the tool surfing the structures does not
> need to know what locators are relevant to the device - something that
> is very device specific.
Right, dv_loc[] would correspond to cf_loc[].