dhcpcd-4.0.0-alpha1 ready for review

[Roy Marples]

OK, some people seem to be genuinely excited about dhcpcd, and others not so
much. So, here's a first draft of dhcpcd-4 :)
You can download a tarball here.
http://roy.marples.name/dhcpcd/dhcpcd-4.0.0-alpha1.tar.bz2

It supplies /etc/dhcpcd.sh which works in pretty much the same way as
dhclient-script. It will configure resolv.conf, ntp.conf, yp.conf and restart
any services for them if it needs to. All variable names that dhclient
emitted are also emitted to dhcpcd.sh so existing customisations stand a good
chance of working.

Interface and routing setup is still done in dhcpcd itself. dhcpcd binary is
now 46k (40k stripped) on NetBSD-4/i386.

New $reason TEST and IPV4LL are emitted.

Stuff that needs to be done
Create man page for dhcpcd.sh
Export classless static routes (option 121) to dhcpcd.sh
Testing! Especially that the correct $reason is set.
Review dhcpcd.sh and ensure that all funtions can be overridden by hook
scripts.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Roy Marples
OK, some people seem to be genuinely excited about dhcpcd, and others not so
much. So, here's a first draft of dhcpcd-4 :)
You can download a tarball here.
http://roy.marples.name/dhcpcd/dhcpcd-4.0.0-alpha1.tar.bz2
It supplies /etc/dhcpcd.sh which works in pretty much the same way as
dhclient-script. It will configure resolv.conf, ntp.conf, yp.conf and restart
any services for them if it needs to. All variable names that dhclient
emitted are also emitted to dhcpcd.sh so existing customisations stand a good
chance of working.

This is great. Thanks!

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Thor Lancelot Simon

Post by Roy Marples
OK, some people seem to be genuinely excited about dhcpcd, and others not so
much. So, here's a first draft of dhcpcd-4 :)
You can download a tarball here.
http://roy.marples.name/dhcpcd/dhcpcd-4.0.0-alpha1.tar.bz2
It supplies /etc/dhcpcd.sh which works in pretty much the same way as
dhclient-script. It will configure resolv.conf, ntp.conf, yp.conf and restart
any services for them if it needs to. All variable names that dhclient
emitted are also emitted to dhcpcd.sh so existing customisations stand a good
chance of working.

This is great. Thanks!

Yes, and it is well written too :-)

- On NetBSD bpf is a cloner and you only need to open /dev/bpf.
- cast ctype arguments to unsigned char and not int, otherwise you silence
the warning but you can still get a core-dump.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Wed, 16 Apr 2008 22:30:04 +0000 (UTC)

Post by Christos Zoulas

Post by Thor Lancelot Simon

Post by Roy Marples
OK, some people seem to be genuinely excited about dhcpcd, and
others not so much. So, here's a first draft of dhcpcd-4 :)
You can download a tarball here.
http://roy.marples.name/dhcpcd/dhcpcd-4.0.0-alpha1.tar.bz2
It supplies /etc/dhcpcd.sh which works in pretty much the same way
as dhclient-script. It will configure resolv.conf, ntp.conf,
yp.conf and restart any services for them if it needs to. All
variable names that dhclient emitted are also emitted to dhcpcd.sh
so existing customisations stand a good chance of working.

This is great. Thanks!

Yes, and it is well written too :-)

I haven't had a chance to look at this. However -- one suggestion I
made about dhclient that might be worth doing here: have a directory of
scripts, with one script per function. That makes it easier to change
one or two, rather than having to edit a large file and track changes
to it.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Christos Zoulas
Yes, and it is well written too :-)
- On NetBSD bpf is a cloner and you only need to open /dev/bpf.
- cast ctype arguments to unsigned char and not int, otherwise you silence
the warning but you can still get a core-dump.

Thanks for those kind words :)
OK, if _PATH_BPF is defined then we now open it instead of searching for a
free BPF device.

I've also changed all instances of my ctype calls I could find to cast to
unsigned.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Steven M. Bellovin
I haven't had a chance to look at this. However -- one suggestion I
made about dhclient that might be worth doing here: have a directory of
scripts, with one script per function. That makes it easier to change
one or two, rather than having to edit a large file and track changes
to it.

What sort of "function" did you have in mind?
script per $reason?
script for ntp, resolv, nis, hostname, etc?

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Thu, 17 Apr 2008 11:03:08 +0100

Post by Roy Marples

Post by Steven M. Bellovin
I haven't had a chance to look at this. However -- one suggestion I
made about dhclient that might be worth doing here: have a
directory of scripts, with one script per function. That makes it
easier to change one or two, rather than having to edit a large
file and track changes to it.

What sort of "function" did you have in mind?
script per $reason?
script for ntp, resolv, nis, hostname, etc?

Yes...

More seriously -- I look at it functionally: what is a user likely to
want to change? You may do some stuff per $reason; you're more likely
to do stuff per area (ntp, resolv, etc.).


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stephen Borrill]

Post by Steven M. Bellovin
On Thu, 17 Apr 2008 11:03:08 +0100

Post by Roy Marples

Post by Steven M. Bellovin
I haven't had a chance to look at this. However -- one suggestion I
made about dhclient that might be worth doing here: have a
directory of scripts, with one script per function. That makes it
easier to change one or two, rather than having to edit a large
file and track changes to it.

What sort of "function" did you have in mind?
script per $reason?
script for ntp, resolv, nis, hostname, etc?

Yes...
More seriously -- I look at it functionally: what is a user likely to
want to change? You may do some stuff per $reason; you're more likely
to do stuff per area (ntp, resolv, etc.).

How about requesting and then dealing with custom options? How about a
flag to specify a list of option numbers (e.g. 151) and this then use
script 'option151'?

[Roy Marples]

Post by Stephen Borrill
How about requesting and then dealing with custom options? How about a
flag to specify a list of option numbers (e.g. 151) and this then use
script 'option151'?

I dislike that as many options are combined into one function.

dns domain name
dns search
dns name servers

Just as an example :)

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Steven M. Bellovin

Post by Roy Marples
What sort of "function" did you have in mind?
script per $reason?
script for ntp, resolv, nis, hostname, etc?

Yes...
More seriously -- I look at it functionally: what is a user likely to
want to change? You may do some stuff per $reason; you're more likely
to do stuff per area (ntp, resolv, etc.).

I suppose the main script could handle resolv.conf and we could then provide
hook scripts for ntp and nis, which people could then use for reference to
make their own.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stephen Borrill]

Post by Roy Marples

Post by Stephen Borrill
How about requesting and then dealing with custom options? How about a
flag to specify a list of option numbers (e.g. 151) and this then use
script 'option151'?

I dislike that as many options are combined into one function.
dns domain name
dns search
dns name servers
Just as an example :)

Indeed, but that doesn't really answer my question about how one might
request and deal with custom options... I use such things with dhclient in
one of our embedded products.

[Roy Marples]

Post by Stephen Borrill
Indeed, but that doesn't really answer my question about how one might
request and deal with custom options... I use such things with dhclient in
one of our embedded products.

dhcpcd can request any option it understands via commandline

dhcpcd -o smtp_server
or
dhcpcd -o 69

Before dhcpcd-4 final is done, we should be able to request options we don't
understand and just dump their contents as dhclient does.

As to dealing with it, well, dhcpcd.sh supports the same enter/exit hooks as
dhclient but also supports directories for each as well.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Thu, 17 Apr 2008 13:17:48 +0100

Post by Roy Marples

Post by Steven M. Bellovin

Post by Roy Marples
What sort of "function" did you have in mind?
script per $reason?
script for ntp, resolv, nis, hostname, etc?

Yes...
More seriously -- I look at it functionally: what is a user likely
to want to change? You may do some stuff per $reason; you're more
likely to do stuff per area (ntp, resolv, etc.).

I suppose the main script could handle resolv.conf and we could then
provide hook scripts for ntp and nis, which people could then use for
reference to make their own.

Actually, I do override resolv.conf -- the default doesn't work well
for me. I run a caching resolver on my laptop, and point resolv.conf
to 127.0.0.1 -- otherwise, applications like firefox have trouble when
I switch locations and the old name servers are no longer reachable.
(I think that OpenBSD checks for resolv.conf changing -- we should
import that code.) So what I do is modify something included by my
named.conf and do a named reload.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stephen Borrill]

Post by Roy Marples

Post by Stephen Borrill
Indeed, but that doesn't really answer my question about how one might
request and deal with custom options... I use such things with dhclient in
one of our embedded products.

dhcpcd can request any option it understands via commandline
dhcpcd -o smtp_server
or
dhcpcd -o 69
Before dhcpcd-4 final is done, we should be able to request options we don't
understand and just dump their contents as dhclient does.
As to dealing with it, well, dhcpcd.sh supports the same enter/exit hooks as
dhclient but also supports directories for each as well.

OK, thanks for the clarification.

[David Laight]

Post by Roy Marples
I've also changed all instances of my ctype calls I could find to cast to
unsigned.

You do mean 'unsigned char' don't you ?

David

[Roy Marples]

Post by David Laight

Post by Roy Marples
I've also changed all instances of my ctype calls I could find to cast to
unsigned.

You do mean 'unsigned char' don't you ?

Yes, sorry for confusion :)

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by David Laight

Post by Roy Marples
I've also changed all instances of my ctype calls I could find to cast to
unsigned.

You do mean 'unsigned char' don't you ?

OK, this piqued my curiosity last night. What would this be expected to do

signed char bar;
unsigned char foo;
foo = (unsigned)bar;

IMO, only two things are possible here
1) type is preserved, so bar is correctly cast to an unsigned char
2) type is silently changed, so bar is incorrectly cast to an unsigned (and I
guess) int

I can't find any documentation on this, so does anyone have any opinion that
can hopefully be backed up with reference documentation?

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

On Apr 18, 9:33am, ***@marples.name (Roy Marples) wrote:
-- Subject: foo = (unsigned)bar; (was Re: dhcpcd-4.0.0-alpha1 ready for revie

| On Thursday 17 April 2008 21:47:25 David Laight wrote:
| > On Thu, Apr 17, 2008 at 11:00:28AM +0100, Roy Marples wrote:
| > > I've also changed all instances of my ctype calls I could find to cast to
| > > unsigned.
| >
| > You do mean 'unsigned char' don't you ?
|
| OK, this piqued my curiosity last night. What would this be expected to do
|
| signed char bar;
| unsigned char foo;
| foo = (unsigned)bar;
|
| IMO, only two things are possible here
| 1) type is preserved, so bar is correctly cast to an unsigned char
| 2) type is silently changed, so bar is incorrectly cast to an unsigned (and I
| guess) int
|
| I can't find any documentation on this, so does anyone have any opinion that
| can hopefully be backed up with reference documentation?

This is not the interesting case, because the end result is the same (i.e
if bar = -2; foo ends up being 254). But if foo was unsigned int, it would
end up being 0xfffffffe, since the bar gets promoted to int (and thus
sign-extended) before being casted to unsigned int.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Roy Marples
signed char bar;
unsigned char foo;
foo = (unsigned)bar;

This extends negative values to int and truncated again to u_char.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alan Barrett]

Post by Roy Marples
OK, this piqued my curiosity last night. What would this be expected to do
signed char bar;
unsigned char foo;
foo = (unsigned)bar;

(unsigned) always means the same as (unsigned int), regardless of the
type of the thing on the right hand side. Similarly,

unsigned foo;

means the same as

unsigned int foo;

Post by Roy Marples
I can't find any documentation on this, so does anyone have any
opinion that can hopefully be backed up with reference documentation?

A web search for "WG14 N1124 pdf" should find the latest committee draft
from shortly before the C99 standard was finalised. Then see section
6.7.2, paragraph 2 read in conjunction with paragraph 5, which makes it
clear that "unsigned" and "unsigned int" mean the same thing in a type
specifier. I'd have to do more work to prove that the same applies to
the thing inside the parentheses of a cast (which is a "type-name", not
a "type specifier").

--apb (Alan Barrett)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Roy Marples
OK, this piqued my curiosity last night. What would this be expected to do
signed char bar;
unsigned char foo;
foo = (unsigned)bar;

What you expect it to do depends on how well you know C. What it does,
conceptually, is

- Sign-extend bar to int.
- Convert that int to unsigned int.
- Truncate that unsigned int to unsigned char
- Store the resulting unsigned char in foo.

On most machines, the "as if" rule lets the compiler convert this into
"move one byte from bar to foo". (Maybe that's true on all machines,
provided you read "byte" as "char-sized unit of memory"; I'd have to
think about it hard to be sure; I suspect non-2's-complement-binary
machines may do something funkier.)

Post by Roy Marples
IMO, only two things are possible here
1) type is preserved, so bar is correctly cast to an unsigned char
2) type is silently changed, so bar is incorrectly cast to an
unsigned (and I guess) int

...huh?

What's incorrect about bar being cast to an unsigned int? That's
exactly what happens (passing through signed int in the process, as
signed char rvalues always do).

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de