etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On 22 May 2002, Eric W. Biederman wrote:
> > > > OK, this I like.  Is there any easy way to identify which rows in pcimap
> > > > correspond to network-card modules?
> > > Cross reference against kernel/drivers/net.
> > > Or look at the class to see if is 0200.  Bu I don't think that is usually
> > > supplied.
> > Some degenerate network drivers can exist outside of kernel/drivers/net -
> > for example in Mandrake 8.2 the prism2 and e100/e1000 family of drivers
> > exist in kernel/3rdparty.  :-(
> > Are there any symbols that all network modules export?  Would this be a
> > viable method for testing?
> Try import and I think it is a viable method.
> I believe init_etherdev and it's cousing functions for initializing
> ethernet cards could be tested for.

I have something pretty close to working.  I'm just running "nm" on all
the kernel modules referenced from modules.pcimap and grepping the output
for "ether" or "wlan".  The automated script builds an initrd and then an
NBI for each network module, and generates a dhcpd.conf fragment that
matches against the encapsulated option etherboot.kmod.  Works with the
only card I've tested it with so far :-)

I've hit one incredibly annoying problem: some modules include the PCI
vendor and device codes but neglect to include a MODULE_DEVICE_TABLE
macro, so their codes are never entered into modules.pcimap.  Very
frustrating, and also explains why my Prism2.5 card didn't get
autodetected despite being perfectly well supported...

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] DHCP option 175

[<ke...@us...>]

>We could assign random arbitrary strings.  But strings that make sense
>in some other context are probably better because someone can look at
>it and make sense of it.  And also be able to predict with some degree
>of accuracy what other ISA chips will have.

It's not too bad. The number of ISA NICs supported by Etherboot is
finite and no new ISA NICs are being designed. We could use the
manufacturer's ID (if available) plus a device ID we invent, possibly
the ur-chip of the family. E.g.

	3c509	VENDOR_3COM	509
	3c515	VENDOR_3COM	515
	NE2000	'NE'		2000
	EEPRO10	VENDOR_INTEL	10
	WD8013	VENDOR_SMC	8013
	Lance	VENDOR_AMD	7990
	CS89x0	VENDOR_CRYSTAL	8900
	DEPCA	VENDOR_DIGITAL	100

It's a different namespace from PCI so clashes won't be a problem. A
couple of passes on this forum and we'll have the table.

Re: [Etherboot-developers] DHCP option 175

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> 
> So is it something that would need to be individually coded into each ISA
> driver, or something that could be coded just once?  

You could do it in one pass but you would have to add it to each driver.
There is no good way for software to identify ISA devices.  And various
tricks are required.

> This is probably a
> stupid question, but I just don't know if the vendor name and part number
> are well-defined fields in the same way as the PCI vendor and device ID
> fields - I never really got into ISA hardware.

They are only well defined in that is what you order the part by.  And
how you look up the parts documentation.  For every bus that came after
ISA; PnPISA, MCA, PCI, USB, ... There are well defined fields you can use
But there is nothing on the software side for ISA.  

We could assign random arbitrary strings.  But strings that make sense
in some other context are probably better because someone can look at
it and make sense of it.  And also be able to predict with some degree
of accuracy what other ISA chips will have.

Eric

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On 22 May 2002, Eric W. Biederman wrote:
> > > > >BTW, where do I get the ID numbers from for ISA cards?  For PCI, I am just
> > > > >using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
> > > > >equivalent for ISA.
> > > > There isn't any that I'm aware of at least for the non-PnP variety. We
> > > > may have to invent some. Possibly 4 distinct bytes from the common name,
> > > > or 2 from the same vendor table, plus 2 made up, might serve.
> > > The only kind of ID I can think of is the vendor name, and part number, of
> > > the ethernet chip.
> > > It might not be the smallest string but it would be something you
> > > could look up.  And it is already distinct for manufacturing and
> > > tracking reasons.
> > Is this information already available somewhere within Etherboot?
> No so that it is trivial to get at.  But basically to actually work
> on the driver that information is needed to look up the documentation.

So is it something that would need to be individually coded into each ISA
driver, or something that could be coded just once?  This is probably a
stupid question, but I just don't know if the vendor name and part number
are well-defined fields in the same way as the PCI vendor and device ID
fields - I never really got into ISA hardware.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] DHCP option 175

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On 22 May 2002, Eric W. Biederman wrote:
> > > >BTW, where do I get the ID numbers from for ISA cards?  For PCI, I am just
> > > >using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
> > > >equivalent for ISA.
> > > There isn't any that I'm aware of at least for the non-PnP variety. We
> > > may have to invent some. Possibly 4 distinct bytes from the common name,
> > > or 2 from the same vendor table, plus 2 made up, might serve.
> > The only kind of ID I can think of is the vendor name, and part number, of
> > the ethernet chip.
> > It might not be the smallest string but it would be something you
> > could look up.  And it is already distinct for manufacturing and
> > tracking reasons.
> 
> Is this information already available somewhere within Etherboot?

No so that it is trivial to get at.  But basically to actually work
on the driver that information is needed to look up the documentation.

Eric

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On 22 May 2002, Eric W. Biederman wrote:
> > >BTW, where do I get the ID numbers from for ISA cards?  For PCI, I am just
> > >using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
> > >equivalent for ISA.
> > There isn't any that I'm aware of at least for the non-PnP variety. We
> > may have to invent some. Possibly 4 distinct bytes from the common name,
> > or 2 from the same vendor table, plus 2 made up, might serve.
> The only kind of ID I can think of is the vendor name, and part number, of
> the ethernet chip.
> It might not be the smallest string but it would be something you
> could look up.  And it is already distinct for manufacturing and
> tracking reasons.

Is this information already available somewhere within Etherboot?

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] DHCP option 175

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On 22 May 2002, Eric W. Biederman wrote:
> > > OK, this I like.  Is there any easy way to identify which rows in pcimap
> > > correspond to network-card modules?
> > Cross reference against kernel/drivers/net.
> > Or look at the class to see if is 0200.  Bu I don't think that is usually
> > supplied.
> 
> Some degenerate network drivers can exist outside of kernel/drivers/net -
> for example in Mandrake 8.2 the prism2 and e100/e1000 family of drivers
> exist in kernel/3rdparty.  :-(
> 
> Are there any symbols that all network modules export?  Would this be a
> viable method for testing?

Try import and I think it is a viable method.

I believe init_etherdev and it's cousing functions for initializing
ethernet cards could be tested for.

Eric

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On 22 May 2002, Eric W. Biederman wrote:
> > In my opinion, ASCII text is always preferred. For DHCPD maintainence
> > binary data is not a good idea ! And the byte space is definitive not
> > critical in this point (3 or 8 bytes ....)
> Given that we have a maximum of 1500 bytes in the DHCP packet, size
> matters a lot.

Is it so critical in the DHCP request packet though?  The DHCP request
packet is probably going to be tiny relative to the DHCP acknowledge
packet.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] DHCP option 175

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >Etherboot will send PCI ID inside vendor-encapsulated-options.
> 
> Another advantage of using VEO is that you get a whole namespace with
> it. If later it's decided that it's a good idea to send the CPU type or
> the memory size, you can allocate further tags in that namespace rather
> than agonise about taking option 176, 177, etc.

As a general rule we should be passing enough information that
a smart host can verify an image will load, and be able to continue
communicating with where it came from.  (So it can load additional
components etc).

To that end I suspect enventually we will need, (especially if we
standardize this, and start working with other implementations).
- CPU family. (X86, Alpha, Hammer, Itanium, PPC, ...)
- Image types accepted. (Tagged, ELF, a.out, COFF, ...)
- Network card (PCI ID or equivalent)
- Usable RAM (roughly the e820 memory map)
- Protocols supported (TFTP, NFS, ...)
   (Though for this a refusing to ack a filename that asks for this
    may be reasonable.)


Eric

Re: [Etherboot-developers] DHCP option 175

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >BTW, where do I get the ID numbers from for ISA cards?  For PCI, I am just
> >using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
> >equivalent for ISA.
> 
> There isn't any that I'm aware of at least for the non-PnP variety. We
> may have to invent some. Possibly 4 distinct bytes from the common name,
> or 2 from the same vendor table, plus 2 made up, might serve.

The only kind of ID I can think of is the vendor name, and part number, of
the ethernet chip.

It might not be the smallest string but it would be something you
could look up.  And it is already distinct for manufacturing and
tracking reasons.

Eric

Re: [Etherboot-developers] DHCP option 175

[<ebi...@ln...>]

Christoph Plattner <chr...@al...> writes:

> In my opinion, ASCII text is always preferred. For DHCPD maintainence
> binary data is not a good idea ! And the byte space is definitive not
> critical in this point (3 or 8 bytes ....)

Given that we have a maximum of 1500 bytes in the DHCP packet, size
matters a lot.
 
> But is the whole stuff really a good idea ?
> Is it important to know the interface on the client side ?
> 
> Normally an admin should know the components, ...
> On the other hand, PCs are quickly exchanged ...
> 
> But should the loaded image not independent of the NIC ?

In general this doesn't work.  If you have a 4M machine you
cannot load a generic kernel.  So knowing both the NIC that
needs to be supported and how much ram is in the box allows
something automatic to build an image, which can load and
tell you everything else that is in the box.

> A Linux kenrel for example should have all needed NIC
> drivers compiled in. The same is for GRUB (after all drivers
> are in the well state, that they do not block in probing
> the NICs).

A generic kernel is 10M try that on a 4M machine.

> The string (option 175) must be very clear and simple,
> and in my opinion TEXT.
> Using PCI ID is perhaps not the best idea ! Perhaps it is a
> better idea to give "keywords" at boot ROM compile time,
> which is passed as tag 175.
> 
> Example: 
> I have a new PC with onboard 3COM another with onboard i82559
> and one with a classic rtl8139 NIC inserted. Then I have to 
> build the 3 boot ROMs, like
> 
> make bin32/3c900.rom KEY175="NEWPC_TYPE_1"
> make bin32/eepro100.rom KEY175="NEWPC_TYPE_2"
> make bin32/rtl8139.rom KEY175="OLDPC_TYPE_1"
> 
> Or in another way.
> (Perhaps we take another build call so that an admin can build
> up and maintain his classes of boot ROMs).

There is probably a decent argument for passing a motherboard id.
However before we start compiling this stuff in let's see how
far we can get with generic code that everyone can use.

Right now a loaded image can pass this information back, and you can
track it by mac address.   The motherboard information is something
you can fairly reliably extract from the DMI tables.  So hard coding
it a build time is probably something we don't want to attack just
yet.

Eric

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On 22 May 2002, Eric W. Biederman wrote:
> > OK, this I like.  Is there any easy way to identify which rows in pcimap
> > correspond to network-card modules?
> Cross reference against kernel/drivers/net.
> Or look at the class to see if is 0200.  Bu I don't think that is usually
> supplied.

Some degenerate network drivers can exist outside of kernel/drivers/net -
for example in Mandrake 8.2 the prism2 and e100/e1000 family of drivers
exist in kernel/3rdparty.  :-(

Are there any symbols that all network modules export?  Would this be a
viable method for testing?

Michael

Re: [Etherboot-developers] DHCP option 175

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On 21 May 2002, Eric W. Biederman wrote:
> > > > Can we change this to return the PCI vendor id and device id's.  This
> > > > makes changes in etherboot transparent to configurations.
> > > > Something like:
> > > > "PCI:8086:1229" for an Intel NIC
> > > > "PCI:10b7:9805" for a 3COM NIC
> > > > For PNPISA devices there is a similiar string we can use.  And for
> > > > straight ISA we might want to just use the vendor and part number.
> > > > Especially as there aren't 1-1 mappings between etherboot and foobar.
> > > This change would make it significantly harder to maintain a DHCP server.
> > > If Etherboot sends the driver name then the DHCP server configuration only
> > > needs to know about the 36 Etherboot drivers.  If Etherboot sends the
> > > vendor and device IDs then the DHCP server configuration needs to know
> > > about the 112 different cards currently in the Etherboot database.
> > > Additionally, new card definitions are likely to be added a lot more
> > > frequently than new drivers(?)
> > But the process could be fully automated by looking at the etherboot
> > database, and the kernel module database (/lib/modules/xxx/pcimap).
> > Both of which are list the vendor id, and device id of the card.   So
> > once setup the worst you will have to do is rerun a script, that
> > accomplishes the mapping.
> > > If there is a better way to achieve this than sending the Etherboot driver
> > > name, please let me know!
> > So in summary I think the PCIID->kernel module mapping is much more
> > of a constant setup situation than sending etherboot driver names.
> > In particular you don't even have care about what etherboot will
> > support you just have to worry about what you can support.
> 
> OK, this I like.  Is there any easy way to identify which rows in pcimap
> correspond to network-card modules?

Cross reference against kernel/drivers/net.
Or look at the class to see if is 0200.  Bu I don't think that is usually
supplied.

Eric

Re: [Etherboot-developers] DHCP option 175

[<ja...@Mc...>]

If you are talking about registering or requesting a number
from IANA, I did that to get an Enterprise ID number for LTSP
by going to the http://www.IANA.org website.

It looks like they have a form you can fill out to request your
dhcp numbers.

Jim McQuillan
ja...@Lt...

On Thu, 23 May 2002, Ken Yap wrote:

> >RFC1533_VENDOR_ETHERBOOT_ENCAP could be set equal to 43 (to use
> >vendor-encapsulated-options) or, alternatively, we could request a DHCP
> >option number from IANA.  The latter may be preferable for two reasons:
> 
> Hmm, does anybody know how the process is initiated?
> 
> Perhaps the time has come for all this option stuff to be cleaned up.
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

-- 

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On Thu, 23 May 2002, Ken Yap wrote:
> >RFC1533_VENDOR_ETHERBOOT_ENCAP could be set equal to 43 (to use
> >vendor-encapsulated-options) or, alternatively, we could request a DHCP
> >option number from IANA.  The latter may be preferable for two reasons:
> Hmm, does anybody know how the process is initiated?
> Perhaps the time has come for all this option stuff to be cleaned up.

According to RFC1533, you have to e-mail ia...@is... and ask.

Michael

Re: [Etherboot-developers] DHCP option 175

[<ke...@us...>]

>RFC1533_VENDOR_ETHERBOOT_ENCAP could be set equal to 43 (to use
>vendor-encapsulated-options) or, alternatively, we could request a DHCP
>option number from IANA.  The latter may be preferable for two reasons:

Hmm, does anybody know how the process is initiated?

Perhaps the time has come for all this option stuff to be cleaned up.

Re: [Etherboot-developers] DHCP option 175

[<ke...@us...>]

>BTW, where do I get the ID numbers from for ISA cards?  For PCI, I am just
>using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
>equivalent for ISA.

There isn't any that I'm aware of at least for the non-PnP variety. We
may have to invent some. Possibly 4 distinct bytes from the common name,
or 2 from the same vendor table, plus 2 made up, might serve.

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On Wed, 22 May 2002, Ken Yap wrote:
> >Etherboot will accept options either "raw" (site-local) or encapsulated in
> >vendor-encapsulated-options, using the same option codes for both cases.
> Hmm? When does Etherboot need to accept PCI IDs? I thought we were
> talking about sending information about the NIC to the server.

I'm also talking about general options: rather than polluting the DHCP
option space it would be nice if all the Etherboot-specific options (e.g.
MOTD strings, the magic number etc.) could be encapsulated in a single
DHCP option.  This would prevent, for example, a DHCP server set up for
Etherboot from mangling the ESSID of Intel Wireless Access Points (which
use option 128 to set the ESSID...).

I've actually coded this up in the last half-hour and will commit soon.
It's a very minor change: basically if Etherboot receives an option with
code RFC1533_VENDOR_ETHERBOOT_ENCAP then it will call decode_rfc1533 on
the contents of the option.

RFC1533_VENDOR_ETHERBOOT_ENCAP could be set equal to 43 (to use
vendor-encapsulated-options) or, alternatively, we could request a DHCP
option number from IANA.  The latter may be preferable for two reasons:

1. It's quite conceivable that a vendor might wish to use Etherboot and
   some of their own (unrelated to Etherboot) DHCP options.  If the
   Etherboot options go in vendor-encapsulated-options then we have yet
   another option-space conflict, just in the vendor-encapsulated-options
   space instead of the "raw" option space.

2. ISC DHCPD seems to have problems with extracting client-sent options
   from vendor-encapsulated-options, although it will happily extract
   options from any other encapsulated option field.

> >Etherboot will send PCI ID inside vendor-encapsulated-options.
> Fine.

Also coded but not yet committed.

BTW, where do I get the ID numbers from for ISA cards?  For PCI, I am just
using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
equivalent for ISA.

Michael

Re: [Etherboot-developers] DHCP option 175

[<ke...@us...>]

>Etherboot will send PCI ID inside vendor-encapsulated-options.

Another advantage of using VEO is that you get a whole namespace with
it. If later it's decided that it's a good idea to send the CPU type or
the memory size, you can allocate further tags in that namespace rather
than agonise about taking option 176, 177, etc.

Re: [Etherboot-developers] DHCP option 175

[<ke...@us...>]

>In my opinion, ASCII text is always preferred. For DHCPD maintainence
>binary data is not a good idea ! And the byte space is definitive not
>critical in this point (3 or 8 bytes ....)

ISC DHCPD's facilities for representing strings is just as good that for
text. Text is just a special case of string where the components are
chars in quotes instead of hex values.

>Normally an admin should know the components, ...

The whole idea is for the admin to need to know less.

>The string (option 175) must be very clear and simple,
>and in my opinion TEXT.

A unjustified bias. Humans will not read the option. It will be used to
direct automatic tools. Say perhaps of a smart DHCPD that can
interpolate values into the filename string, which can then trigger a
smart TFTPD to build an image on the fly.

>Using PCI ID is perhaps not the best idea ! Perhaps it is a
>better idea to give "keywords" at boot ROM compile time,
>which is passed as tag 175.

The whole idea is not to have to specify anything. The code just passes
the information up to the DHCP server and the software
selects/constructs the right image.

This complements the method used by LTSP which is a probe from a
ramdisk.  In some uses of Etherboot, having to boot a kernel to
determine what module to load, may be too heavyweight. This ID mechanism
can also be used by other operating systems.

Re: [Etherboot-developers] DHCP option 175

[<ke...@us...>]

>Etherboot will accept options either "raw" (site-local) or encapsulated in
>vendor-encapsulated-options, using the same option codes for both cases.

Hmm? When does Etherboot need to accept PCI IDs? I thought we were
talking about sending information about the NIC to the server.

>Etherboot will send PCI ID inside vendor-encapsulated-options.

Fine.

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On Wed, 22 May 2002, Christoph Plattner wrote:
> In my opinion, ASCII text is always preferred. For DHCPD maintainence
> binary data is not a good idea ! And the byte space is definitive not
> critical in this point (3 or 8 bytes ....)

I have a slight preference for ASCII text, but it's not really a big
issue: you can just use some of the functions listed in dhcp-eval(5) to
generate the ASCII equivalent from the binary data.

> But is the whole stuff really a good idea ?
> Is it important to know the interface on the client side ?

Yes, if it affects the kernel+initrd that the client should use.

> Normally an admin should know the components, ...
> On the other hand, PCs are quickly exchanged ...

IMO, anything that decreases maintenance requirements from O(n) or above
down to O(1) is a good thing.

> But should the loaded image not independent of the NIC ?
> A Linux kenrel for example should have all needed NIC
> drivers compiled in.

Most distributions ship with modularized kernels.  Since it's possible to
use these kernels to boot diskless terminals via Etherboot (with an
appropriate initrd), why should we force users to recompile their kernel?

> Using PCI ID is perhaps not the best idea ! Perhaps it is a
> better idea to give "keywords" at boot ROM compile time,
> which is passed as tag 175.
> Example:
> I have a new PC with onboard 3COM another with onboard i82559
> and one with a classic rtl8139 NIC inserted. Then I have to
> build the 3 boot ROMs, like
> make bin32/3c900.rom KEY175="NEWPC_TYPE_1"
> make bin32/eepro100.rom KEY175="NEWPC_TYPE_2"
> make bin32/rtl8139.rom KEY175="OLDPC_TYPE_1"

This is more than O(1); it requires the administrator to manually maintain
parts of dhcpd.conf that could be handled completely automatically.  Using
the PCI IDs means that an administrator need never touch or even look at
the Etherboot-specific parts of dhcpd.conf.


I think this scheme could work well alongside the send-the-PCI-ID scheme.
Etherboot can always send the PCI ID and for most cases this is all that
will be needed.  The dhcpd server can be configured such that Etherboot
clients will work instantly without any manual changes required by the
administrator.  For the few cases when the PCI ID is insufficient to
determine the card configuration, an additional (vendor-encapsulated)
option can be used to pass an arbitrary keyword defined at build time in
the way you describe.

Michael

Re: [Etherboot-developers] DHCP option 175

[Michael B. <mb...@fe...>]

On Wed, 22 May 2002, Ken Yap wrote:
> >> Also I'd prefer that this tag be encapsulated inside one of the standard
> >> tags for this sort of client info, perhaps even the
> >> vendor-class-identifier tag to avoid using 175.
> >It could be wrapped up in vendor-encapsulated-options.  I chose 175 in
> >order to fit in with the current scheme which, AFAICT, uses the site-local
> >DHCP options (128-254) instead of encapsulation.
> True, but those were the bad old days.

:o)

OK, how about this:

Etherboot will accept options either "raw" (site-local) or encapsulated in
vendor-encapsulated-options, using the same option codes for both cases.

Etherboot will send PCI ID inside vendor-encapsulated-options.



DHCP servers configured to work without encapsulation will continue to
work with new Etherboot code (since Etherboot will accept both raw and
encapsulated options).

DHCP servers will know that if the Etherboot request includes a
vendor-encapsulated-options option then they can reply using encapsulated
options.  Otherwise, they should return the raw options in order to
maintain backwards compatibility with older BootROMs.


I'll knock something up to implement this unless there are more objections
:-)

Michael

Re: [Etherboot-developers] DHCP option 175

[Christoph P. <chr...@al...>]

In my opinion, ASCII text is always preferred. For DHCPD maintainence
binary data is not a good idea ! And the byte space is definitive not
critical in this point (3 or 8 bytes ....)

But is the whole stuff really a good idea ?
Is it important to know the interface on the client side ?

Normally an admin should know the components, ...
On the other hand, PCs are quickly exchanged ...

But should the loaded image not independent of the NIC ?
A Linux kenrel for example should have all needed NIC
drivers compiled in. The same is for GRUB (after all drivers
are in the well state, that they do not block in probing
the NICs).

The string (option 175) must be very clear and simple,
and in my opinion TEXT.
Using PCI ID is perhaps not the best idea ! Perhaps it is a
better idea to give "keywords" at boot ROM compile time,
which is passed as tag 175.

Example: 
I have a new PC with onboard 3COM another with onboard i82559
and one with a classic rtl8139 NIC inserted. Then I have to 
build the 3 boot ROMs, like

make bin32/3c900.rom KEY175="NEWPC_TYPE_1"
make bin32/eepro100.rom KEY175="NEWPC_TYPE_2"
make bin32/rtl8139.rom KEY175="OLDPC_TYPE_1"

Or in another way.
(Perhaps we take another build call so that an admin can build
up and maintain his classes of boot ROMs).

With this method, the maintainer can handle equal or different
types of NICs and machines. Often 2 NICs of the same type may
need different options, etc....


With friendly regards
Christoph



Ken Yap wrote:
> 
> >How about this standard for the NIC tag?
> >
> >       "PCI" or "ISA" (3 bytes)
> 
> Actually that's probably a waste of space, binary 1 = PCI, 2 = ISA,
> others for later use should suffice.
> 
> >       Vendor ID (2 bytes network order)
> >       Device ID (2 bytes network order)
> 
> 6 bytes total.
> 
> As for any potential objection that it's unreadable binary, the rest of
> the DHCP packet is unreadable binary anyway, space matters (the more
> parsimonious you are with your options, the more space for other
> options), and it makes the Etherboot shorter, just copy in the IDs, via
> htons().
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
  +--------V--------+	Chr...@al...
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

Re: [Etherboot-developers] DHCP option 175

[<ke...@us...>]

>> Also I'd prefer that this tag be encapsulated inside one of the standard
>> tags for this sort of client info, perhaps even the
>> vendor-class-identifier tag to avoid using 175.
>
>It could be wrapped up in vendor-encapsulated-options.  I chose 175 in
>order to fit in with the current scheme which, AFAICT, uses the site-local
>DHCP options (128-254) instead of encapsulation.

True, but those were the bad old days.