Re: PR 49430

[christos%zoulas.com@localhost (Christos Zoulas)]

On Nov 25,  4:08pm, fleshenough%gmail.com@localhost (Kyle Amon) wrote:
-- Subject: Re: PR 49430

| > On Nov 22,  7:35pm, amonk%riseup.net@localhost (amonk%riseup.net@localhost) wrote:
| > -- Subject: PR 49430
| >=20
| > Sorry, I did not notice this before... There is a bug here, but it is
| > in opendisk(3) and since it is documented, it is not really a bug.
| >=20
| > Now what's going on is that you named you parameter file for cgd0
| > "cgd0" which is ok. But then what happens is that cgdconfig cd's in
| > /etc/cgd and in line 14 it sees "cgd0" and runs opendisk on it. Since
| > it finds the file "cgd0" there, it opens that instead of the device
| > /dev/cgd0d and so when it runs ioctl to configure it, it fails.
| > If you change the line to read /dev/cgd0 instead of cgd0 or the
| > params file cgd0.params instead of cgd0 things should work.
| >=20
| > But don't close the PR because:
| > 1. I don't know what business has cgdconfig running chdir(2); seems bogus
| >    to me.
| > 2. The error message from cgdconfig should not lose the information about
| >    why the action failed in the first place and should communicate it to
| >    the user.
| >=20
| > christos
| 
| Christos,
| 
| Thanks, but it seems to me that cgdconfig is trying to be too smart then
| and ending up being braindead instead.  Why is it calling opendisk(3) on a
| *regular* file that's not even in /dev just because it happens to "notice"
| it exists and is similarly named to the actual device?  It seems that it is
| getting "confused" by its inappropriate assumptions about a mere label and
| associated mere parameter file and thus trying open a regular file, not
| even under /dev, as a device (without so much as checking if this
| "discovered" file even actually is a device).  Furthermore, all this in
| spite of the fact that the *target* in the config file is clearly
| identified as /dev/ld0b, an obvious component of /dev/ld0d, of course.
| What's the point of even defining the actual target there if that
| information is going to be ignored based on assumptions about mere labels?
| All of this sure sounds like a bug in cgdconfig to me.  As you've said
| yourself, naming the parameter file cgd0 "is OK" (which I was indeed
| careful to verify before so doing). The first field in the config file is
| a mere label, and prepending a /dev to it is needlessly confusing and
| *should* not be required for things to actually work.  I guess I can live
| with appending a .params to my params file (or otherwise changing its
| name), if I must, but it seems to me that I should not have to do so.  It
| seems to me like a bug in cgdconfig.  But, yes, I agree that the likely
| inadvisable chdir(2) is a least contributing to the problem.  However,
| while it may not technically be a bug in opendisk(3) for it to try to open
| regular files, it sure seems like it would be a wise feature for it to at
| least check if a file to be opened is either a block or character special
| file before doing so, and passing the reason for such failures/refusals
| back to the user.  I mean, it's called openDISK, after all (lol).  Thanks
| for your attention and explanation.  Sorry I finally got a little pissy.  I
| will append a .params to my params file, which is certainly more elegant
| than my current workaround.

Or you can cvs update cgdconfig to head and your current setup will work.
I said I was going to fix it and what cgdconfig was doing was not
satisfying POLA.

christos