On Wed, 25 Nov 2015 19:42:09 -0500
christos%zoulas.com@localhost (Christos Zoulas) wrote:
> 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
Cool. Thanks. I'm all warm and fuzzy now. :)
--Kyle
--
CA +1-778-819-UNIX http://gnutec.ca/~amonk
US +1-425-584-UNIX Neglected since March 20, 2003
SIP amonk%backwatcher.com@localhost @fleshenough
INUM +883-5100-0990-1657
ISN UNIX*1917
GPG F36E1CAB / CF001165F36E1CAB
6050 05B7 9FF1 CC21 3F00 CEBB CF00 1165 F36E 1CAB
OTR 1B8CA85B 9696C3E0 CDE79B77 52D5F7E6 5492DBE2 : jabber/backwatcher.org
5CF381C0 5F74307B 082E63E9 9EC509FA 85486180 : jabber/riseup.net
3614B012 C81F85FD 71FC48A4 75D88B91 A0203B51 : jabber/jabber.ru
DC446975 0D1CC62D 092E633C 2E3D3D82 B4CE1C47 : freenode
B4B825A3 086F0716 2CA55061 A0F521EB 54C0AB2F : oftc
744D942C D581087C ADDB11D2 E8E9FF59 B46481F3 : efnet
4443188D 5CA26B63 6327F9CD 3349C795 7743110D : facebook
4FB85A74 B2E1BBE3 20CD282E 8E8DD9B3 30EDAAC3 : google
B0C46C9E DD3685C8 81182D51 B2D14BE9 A43CFE09 : icq
41D60F67 7441ACFF 32CC2BF7 4EE70B17 08DA044F : aim
30CD13B4 A25DAC7A 863F638A 9EE95FBB 15D320A9 : yahoo
9FE919C7 7FD23FCB 5FF12636 A1F571B9 104AE5C1 : skype
NSA cyclonite, hexogen, torpex, cyclotol, semtex, fukq, heh, heh
Attachment:
pgpbcecsQYxK9.pgp
Description: OpenPGP digital signature