After previous discussion, here is my plan for getting compressed vnd(4)
etc. into the tree:
* Transform .list files to .xml files in htdocs that mention vnconfig(8)
(preparation), DNE
* rename vnconfig(8) to vndconfig(8)
* fix related documentation in src
* fix related documentation in htdocs
* commit the kernel and userland part for compressed vnd(4)
* import vndcompress(1)
I intend to do this within the next few days, so if there are any
objections, should NW!
FWIW the current code will used on a Live CD that will be available in
German language in a german magazine in ~2 Months, and an international
version of the CD will be available for the Systems roadshow in Germany in
fall.
- Hubert

Fri, Jul 15, 2005 at 07:16:14PM +1000, matthew green wrote:

i see no reason for /usr/sbin/vnconfig to ever go away. add a vndconfig

The name is misleading. If we have a non-misleading (read: right) executable
in the system, the misleading (read: wrong) one must go away sooner or later.

The only reason to make up another inconsistent way (based on an inconsistent
way) is to make the migration (of scripts for example) easier.

The idea of a warning message is good. I'd say "neccessary".

>i see no reason for /usr/sbin/vnconfig to ever go away.
The name is misleading.

What is misleading about it? What error does it confuse you, or
others, into making?

I don't see it as any more confusing than, say, ifconfig, or wiconfig -
or for that matter ls or fsplit.

/~\ The ASCIIder Mouse
\ / Ribbon Campaign
X Against HTML mouse (AT) rodents (DOT) montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Fri, 15 Jul 2005, Allen Briggs wrote:
I'm inclined to say that there should be a transition period where
vnconfig is a hard link to vndconfig. I don't run the command by
hand, but it seems that the name change is not strictly necessary,
and I'd hate to break scripts, etc., by removing vnconfig immediately.
At least make a mention of it in a public place (CHANGES or something)
and provide some time (a release cycle?) for the transition.

I see that we move things around all the time, without providing backward
compatibility. And it was suggested to rename vnconfig to vndconfig to
match the driver's name (vnd(4)), so the thing was mis-named in the first
place, and I won't jump through even more hoops to get this done.
course I intend to make an entry in src/doc/CHANGES that it was
renamed, and I'll even go into src and htdocs and change all places (I'm
tempted to start rambling about how others don't change documentation when
code changes).

As an alternative, I can leave it at vnconfig.

- Hubert

Fri, Jul 15, 2005 at 04:11:45PM +0200, Hubert Feyrer wrote:
As an alternative, I can leave it at vnconfig.
I would rather it be renamed to vndconfig. But if it is left as
vnconfig, then it would be good to clear the BUGS section of
vnconfig(8).
Cheers,
Ben

Fri, Jul 15, 2005 at 09:31:08AM -0400, der Mouse wrote:
>i see no reason for /usr/sbin/vnconfig to ever go away.
The name is misleading.

What is misleading about it? What error does it confuse you, or
others, into making?

The driver is called "vnd". Vnode Disk Driver. The configuration utility
is called "vnconfig". For what reason? course, Vnode Disk Config and
Vnode Disk Driver Config are essentially the same - but I always write
"vndconfig" - it is just natural to me.

I don't see it as any more confusing than, say, ifconfig, or wiconfig -
Given the context from above, you cannot compare vn{d,config} to {if,wi}config.

Fri, Jul 15, 2005 at 04:11:45PM +0200, Hubert Feyrer wrote:

Fri, 15 Jul 2005, Allen Briggs wrote:
>I'm inclined to say that there should be a transition period where
>vnconfig is a hard link to vndconfig. I don't run the command by
>hand, but it seems that the name change is not strictly necessary,
>and I'd hate to break scripts, etc., by removing vnconfig immediately.
>At least make a mention of it in a public place (CHANGES or something)
>and provide some time (a release cycle?) for the transition.

I see that we move things around all the time, without providing backward
compatibility. And it was suggested to rename vnconfig to vndconfig to
match the driver's name (vnd(4)), so the thing was mis-named in the first
place, and I won't jump through even more hoops to get this done.

Wait. You're saying we should do something because it's the right thing
(naming the program vndconfig), but in the same breath you're saying you
won't do something that is also the right thing (making a transition
point)? That's not very nice. :-)

I think the renaming is the only thing I object to in all of this.

course I intend to make an entry in src/doc/CHANGES that it was
renamed, and I'll even go into src and htdocs and change all places (I'm
tempted to start rambling about how others don't change documentation when
code changes).

As an alternative, I can leave it at vnconfig.

How about this as an alternative (assuming my make syntax is right :-) :

LINKS=${BINDIR}/vnconfig ${BINDIR}/vndconfig
MKINKS= vnconfig.8 vndconfig.8

I'm not sure if you need to include bsd.links.mk. I suspect it's already
included.

I'm not at all opposed to having vndconfig. I'd like that. A lot. However
we've had "vnconfig" since NetBSD 1.0, and I think we should continue the
name. Given that keeping it only costs a dirent worth of disk (for the
second link), it's rather cheep.

I also would like us to keep the original source files around. I'm a big
fan of revision history. While it may not matter for these files, we do
have 29 revisions for the man page and 32 for the program. I'd rather they
stay where we can easily find them. :-)

Take care,

Bill

PGP SIGNATURE
Version: GnuPG v1.2.3 (NetBSD)

7B9kdhK8UCFLxglK5LpuDP8=
=PNCb
PGP SIGNATURE

The name [vnconfig] is misleading.
>What is misleading about it? I don't see it as any more confusing
>than, say, ifconfig, or wiconfig -
The configuration utility is called "vnconfig". For what reason?

Reason? I don't know the reason. I didn't name either of them.
Unless "history" is the sort of answer you want.

Given the context from above, you cannot compare vn{d,config} to
{if,wi}config.

I'm not. I'm comparing vnd/vnconfig to {ex,fxp,le,qe,ep,}/ifconfig
and whatever/wiconfig.

I don't find the one significantly more confusing, or misleading, than
the other.

/~\ The ASCIIder Mouse
\ / Ribbon Campaign
X Against HTML mouse (AT) rodents (DOT) montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Fri, Jul 15, 2005 at 11:36:05AM +0200, Sascha Retzki wrote:
Fri, Jul 15, 2005 at 07:16:14PM +1000, matthew green wrote:

i see no reason for /usr/sbin/vnconfig to ever go away. add a vndconfig

The name is misleading. If we have a non-misleading (read: right) executable
in the system, the misleading (read: wrong) one must go away sooner or later.

"must"?

Wed, Jul 13, 2005 at 07:49:14PM +0200, Hubert Feyrer wrote:
| After previous discussion, here is my plan for getting compressed vnd(4)
| etc. into the tree:
|
| * rename vnconfig(8) to vndconfig(8)

Please retain the old name for compatibility. I.e., have both names.
We have prior art for this already (systat / sysstat).

PGP SIGNATURE
Version: GnuPG v1.4.1 (NetBSD)

JBRdHeTLLRyFmVsjT3eI4Cg=
=DgFe
PGP SIGNATURE

Salut,

Sat, Jul 16, 2005 at 03:13:01PM +1000, Luke Mewburn wrote:
Wed, Jul 13, 2005 at 07:49:14PM +0200, Hubert Feyrer wrote:
| After previous discussion, here is my plan for getting compressed vnd(4)
| etc. into the tree:
|
| * rename vnconfig(8) to vndconfig(8)

Please retain the old name for compatibility. I.e., have both names.
We have prior art for this already (systat / sysstat).

Which, in my opinion, doesn't really help to decrement confusion

Anyway, looking at it from a positivist point of view, it's a really
fnordic idea.

Tonnerre

PGP SIGNATURE
Version: GnuPG v1.4.1 (NetBSD)

cNUqUdVfbUDJMsYM=
=1/qu
PGP SIGNATURE

Sat, 16 Jul 2005, Tonnerre wrote:
>Please retain the old name for compatibility. I.e., have both names.
>We have prior art for this already (systat / sysstat).
>
Which, in my opinion, doesn't really help to decrement confusion

Indeed reminds me of "zast" on some SuSE systems
(on german keyboards, the 'z' is there the 'y' is on US keyboards and vice
versa, so for people that get hit by an unknown/US keyboard, there's that
alternative name). I'd prefer not to go that way.

- Hubert

Wed, 13 Jul 2005, Hubert Feyrer wrote:
* Transform .list files to .xml files in htdocs that mention vnconfig(8)
(preparation), DNE
* rename vnconfig(8) to vndconfig(8)
* fix related documentation in src
* fix related documentation in htdocs
* commit the kernel and userland part for compressed vnd(4)
* import vndcompress(1)

After the recent discussion about the step that leads to the most work
(renaming vnconfig->vndconfig), here's an updated roadmap:

1) commit kernel and userland part for reading compressed vnd(4)
2) import vndcompress(1)
3) See what to do with vnconfig(8)

- Hubert

>After previous discussion, here is my plan for getting compressed vnd(4)
>etc. into the tree:

* Transform .list files to .xml files in htdocs that mention vnconfig(8)
(preparation), DNE
* rename vnconfig(8) to vndconfig(8)

Sorry, but why the rename?

>i see no reason for /usr/sbin/vnconfig to ever go away. add a vndconfig

>The name is misleading. If we have a non-misleading (read: right) executable
>in the system, the misleading (read: wrong) one must go away sooner or later.

Why _must_ it go away, and _who_ says it is missleading?
vnconfig is the command i've used in many scripts for several years,
and now I find I was wrong all that time

>The only reason to make up another inconsistent way (based on an inconsistent
>way) is to make the migration (of scripts for example) easier.

Which is a big deal actually. renaming things just for "correctness"
isn't necessarily a win.

>The idea of a warning message is good. I'd say "neccessary".

Again, why? Reminds me of the silly warning that nslookup now
issues on some systems.