NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PR 49430

On Wed, 25 Nov 2015 19:42:09 -0500 (Christos Zoulas) wrote:

> On Nov 25,  4:08pm, (Kyle Amon) wrote:
> -- Subject: Re: PR 49430
> | > On Nov 22,  7:35pm, ( 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. :)


  CA +1-778-819-UNIX            
  US +1-425-584-UNIX                      Neglected since March 20, 2003
 SIP                @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/
    5CF381C0 5F74307B 082E63E9 9EC509FA 85486180 : jabber/
    3614B012 C81F85FD 71FC48A4 75D88B91 A0203B51 : jabber/
    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

Home | Main Index | Thread Index | Old Index