From: g_remlin <g_remlin@rocketmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] CONFIG_BOOTP_VENDOREX ???, I'm a newbie
Date: Wed, 06 Oct 2010 20:16:33 +0100 [thread overview]
Message-ID: <4CACCB11.9040306@rocketmail.com> (raw)
I want 'options' processing in the dhcp client to permit
setting\sending 'user-class' and the like via the environment. I found
CONFIG_BOOTP_VENDOREX (with it's functions 'dhcp_vendorex_prep' &
'dhcp_vendorex_proc' ) used in a handful of boards, which looks like it
was intended for a similar purpose.
As dhcp supports the processing of non-standard options through it's
expression evaluation support:
Why are vendor specific options implemented this way at all ?
Why specifically for only a handful of boards, and not globally for
anything bootp capable ?
Why does it support current standard (term used vaguely) dhcp options
rather than something 'vendor specific' as the name implies ?
And now to the point - Should I replace it or fudge around it ?
Yes, I am a total newbie to free open source collaborative programming.
Yes, I need my hand held (everybody had to start for the first time
sometime).
If an individual or 'the list' is willing to mentor me, I am prepared to
put in the effort to attempt to implement the basic skeleton in a form
that can be submitted. A typical type of question any mentor could
expect is most likely to be 'political' i.e. :
Currently the convention for environment variable naming appears to me
to be a little sketchy. Visually scanning a complex environment is
becoming more tedious as the number of options increase, when would be a
good time to do something about this ?
I propose (that I implement dhcp options processing with) the use of
upper case prefixes to denote a particular variable class.
For example:
setenv DHCP_user-class 'cluster01'
setenv DHCP_vendor-class-identifier 'Marvell'
and later this class prefixing could optionally be extended to encompass
the variables already defined as required.
Gray Remlin - comments invited.
reply other threads:[~2010-10-06 19:16 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CACCB11.9040306@rocketmail.com \
--to=g_remlin@rocketmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.