Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Dec 2001 18:08:00 -0500
From:      The Anarcat <anarcat@anarcat.dyndns.org>
To:        arch@freebsd.org
Cc:        jkh@freebsd.org
Subject:   sysctl kern.disks shouldn't have to sort its output
Message-ID:  <20011222230759.GD530@shall.anarcat.dyndns.org>

next in thread | raw e-mail | index | archive | help

--3O1VwFp74L81IIeR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi.

I'm struggling with a breakage in libh which is due to some code
committed recently to -stable libdisk and then MFS'd to -current:

-- snip --
revision 1.50.2.14
date: 2001/09/18 06:47:30;  author: jkh;  state: Exp;  lines: +2 -2
Temporarily disable the use of kern.disks - it returns the disk
devices in the wrong order and causes them to be displayed out of
sequence in sysinstall.  The right fix is to sort that info in the
kernel, this is just a stop-gap measure which falls back to the code
which always ran prior to kern.disks existing.  This deliberately
not committed to -current because we have aple time to pursue the
right fix in that branch.
-- snip --

The breakage is that the "alternate drive detection routine" uses a open
call on the drive device to verify that it exists. It is not only
inefficient, but also disables detection for non-root processes.

Ok, now, i'm not sure about that, but looking at how kern.disks is
implemented (a simple list to which disks are added one by one) and how
sysctl_disks is implemented (iteration through that list), it seems a
pain to sort these entries there.

To me, the sorting belongs to libdisk at most, or to the user app.

Not in the kernel.

Of course, one might wonder why the entries in kern.disks are not
sorted. This, I do not know. It might depend on how the disks are
detected. For example, here, sysctl kern.disks gives:

kern.disks: cd0 ad3 ad1 ad0 md0

ad3 is on ata1. So maybe ata1 is detected first and that's why the disk
ends up there. I don't know.

Anyways. If the sorting belongs to the kernel, I could do it.

However, I think it belongs to libdisk, so I'll start working on a patch
there.

Just FYI,

a.

--3O1VwFp74L81IIeR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwlEkwACgkQttcWHAnWiGfq9gCdE67OTyktP7Ec2nv5JiY/Qjom
RaoAn2ztR7R2b3Qp9Q1gTf0Z10RSmUV3
=u5Qh
-----END PGP SIGNATURE-----

--3O1VwFp74L81IIeR--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011222230759.GD530>