The following reply was made to PR kern/34085; it has been noted by GNATS.

From: Quentin Garnier <cube@cubidou.net>
To: gnats-bugs@NetBSD.org
Cc: christianbiere@gmx.de
Subject: Re: kern/34085: "scsibus* at umass?" missing for GENERIC kernel
Date: Wed, 26 Jul 2006 15:11:03 +0200

 --J/BDJo4Yjy3b8E62
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Wed, Jul 26, 2006 at 12:35:02PM +0000, Christian Biere wrote:
 > The following reply was made to PR kern/34085; it has been noted by GNATS.
 >=20
 > From: Christian Biere <christianbiere@gmx.de>
 > To: gnats-bugs@NetBSD.org
 > Cc:=20
 > Subject: Re: kern/34085: "scsibus* at umass?" missing for GENERIC kernel
 > Date: Wed, 26 Jul 2006 14:39:38 +0200
 >=20
 >  Quentin Garnier wrote:
 >  > > The following line is missing in the GENERIC kernel for several
 >  > > platforms:
 > =20
 >  > > scsibus* at umass? channel ?
 >  > No, it's not missing.
 >  =20
 >  > It's not that you can't have it;  you very well can, and the alpha
 >  > config proves it.  My point is that if you have "scsibus* at scsi?",
 >  > you don't need it.
 > =20
 >  As said, I booted a GENERIC kernel and there was no sd* to mount. I
 >  have also a digital camera which is mounted as storage device over
 >  USB. That one worked out-of-the-box IIRC but that one uses atapibus*.
 > =20
 >  The only SCSI-relevant line in the boot messages was
 >  "scsibus0: device not configured"
 > =20
 >  (or similar)
 > =20
 >  > That's the thing:  if "scsibus* at scsi?" appears before the
 >  > instance attaching at umass, the latter will never even be
 >  > considered by autoconf(9) because the two are semantically
 >  > equivalent for an attachment at umass.
 > =20
 >  Indeed I appended the line "scsibus* at umass?" without "channel?"
 >  actually. Contrary to what you write, this does work. I did not
 >  comment out the existing line.
 
 That's most surprising.  There might be a bug, as that line appeared
 and disappeared a couple times because people thought it was necessary.
 Nobody could give me material about it so far, though.
 
 For the record:
 
 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/conf/GENERIC#rev1.683
 
 >  > So if you have the two lines, you're actually wasting the few bytes
 >  > of a cfdata structure.
 > =20
 >  That's why I wrote, ``comment it out if desired''. As you can imagine
 >  I really don't care about this minor wastage in my case as long as it
 >  works but I'll comment out the "scsibus* at scsi?" line if you say
 >  only one of them is necessary.
 
 They have different semantics:  "scsibus* at scsi?" will allow the
 attachment of a scsibus device on any device providing the scsi
 attribute (which, of course, umass does).  "scsibus* at umass?" will
 only allow attachment of a scsibus device on a umass device.  My point
 is that the latter is redundant when the former is already present, but
 they are certainly not equivalent.
 
 >  > I'll probably fix scsibus.4, too, although it's interesting to have
 >  > a list somewhere of the devices that expose the scsi attribute, so
 >  > it does make sense to have it that way.
 > =20
 >  I see you removed the relevant hint from scsibus(4). I doubt that
 >  I would have figured out how to tweak the kernel configuration to
 >  get the device working.
 
 I'll re-add the list somehow, but it has to be done properly.
 
 >  Is there something I'm missing? Does the GENERIC kernel now find
 >  and configure such devices? I'm really confused because to me it
 >  looks things just got worse due to my change request. I will be
 >  more careful with my suggestions in the future.
 
 What you're missing is that the bug is not that the line should be added
 in the config file, the bug is that it is doesn't work with the
 attachment to "scsi?".  I've never seen a device that triggers that bug,
 so I'm still rather doubtful about it.  The code is rather simple there.
 
 I'd like to see the dmesg(1) output in both case, with the matching
 kernel configuration.  All complete, no excerpts.
 
 My whole point here is that the inconsistencies between configuration
 files and scsi(4) misguided you in the analysis of the issue.  That's
 the confusion;  hence my commits this morning.  Now, if there is
 indeed a bug, let's track it down properly.
 
 --=20
 Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
 "When I find the controls, I'll go where I like, I'll know where I want
 to be, but maybe for now I'll stay right here on a silent sea."
 KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
 
 --J/BDJo4Yjy3b8E62
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.3 (NetBSD)
 
 iQEVAwUBRMdp59goQloHrPnoAQLbKgf/W9VzH8xNNAB9oU2WgE53wmxObbeFFZ/0
 1122489cJQ37LHL9xcdDmLq6ZPf8qmrzvBfFe1nwXokqa6VPyKcGTUwT++VyJK+j
 LIm/IhPzaGs+Wu3zbFFMESXy1+inN8u5tDslWLbxl4Wkxh0RUFh5IwzFqikelNwJ
 O7pw5rRa+8bfotNWam2QxE9KOdGc11oaJ98SFPAWGJPExnXkCGO3QpjDE7cW7Ruy
 g1PyqcDlG4DrMrcPtuEKuCSAffRFu8w5AEuzMbTZ+tKjJiKP0CLdCRtIhfxVYd4+
 FUj46VgB17cgMk35y2yd3qWZKU2RQbbpK0ycAPEmB2jBo2Ur2Rzang==
 =NE8D
 -----END PGP SIGNATURE-----
 
 --J/BDJo4Yjy3b8E62--