From owner-freebsd-arch Sat Dec 22 16:55:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tomts11-srv.bellnexxia.net (tomts11.bellnexxia.net [209.226.175.55]) by hub.freebsd.org (Postfix) with ESMTP id 3FB6A37B416; Sat, 22 Dec 2001 16:55:09 -0800 (PST) Received: from khan.anarcat.dyndns.org ([65.94.189.35]) by tomts11-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20011223005507.IENR8040.tomts11-srv.bellnexxia.net@khan.anarcat.dyndns.org>; Sat, 22 Dec 2001 19:55:07 -0500 Received: from shall.anarcat.dyndns.org (shall.anarcat.dyndns.org [192.168.0.1]) by khan.anarcat.dyndns.org (Postfix) with ESMTP id D0EA11B38; Sat, 22 Dec 2001 19:55:03 -0500 (EST) Received: by shall.anarcat.dyndns.org (Postfix, from userid 1000) id A632F20ACB; Sat, 22 Dec 2001 19:54:50 -0500 (EST) Date: Sat, 22 Dec 2001 19:54:50 -0500 From: The Anarcat To: Jordan Hubbard Cc: arch@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: sysctl kern.disks shouldn't have to sort its output Message-ID: <20011223005449.GE530@shall.anarcat.dyndns.org> References: <20011222230759.GD530@shall.anarcat.dyndns.org> <33483.1009066876@winston.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7uYPyRQQ5N0D02nI" Content-Disposition: inline In-Reply-To: <33483.1009066876@winston.freebsd.org> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --7uYPyRQQ5N0D02nI Content-Type: multipart/mixed; boundary="bGR76rFJjkSxVeRa" Content-Disposition: inline --bGR76rFJjkSxVeRa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat Dec 22, 2001 at 04:21:16PM -0800, Jordan Hubbard wrote: > > Anyways. If the sorting belongs to the kernel, I could do it. > >=20 > > However, I think it belongs to libdisk, so I'll start working on a patch > > there. >=20 > The sorting could be in libdisk, I just suggested the kernel so that > other consumers of the kern.disks sysctl variable wouldn't have to > sort it as well.=20 Yes, of course. But I wonder how best it would be implemented... By controlling how entries are added to the list, or by controlling how he prints those entries? Because it is a list, sorting it is not very efficient. At the output though (outside sysctl_disks and therefore outside the kernel), it's a string, so it's easier to manipulate. I think a list-sorting algorithm for that little thing would be a bloat in the kernel. Also, if we can figure out where the order comes from, we might want to keep it unsorted, as a feature. :P Am I wrong? > One assumes that more than libdisk might want to get > at this data.=20 Then these consumers have to assume that the data is unsorted. Anyways, it's much easier to do it oustide the kernel. > In any case, for this particular case doing it in > libdisk would be fine. Here is a quick hack on libdisk to deal with this. It uses qsort since I wanted to see how it works but anyone is free to implement its own algorithm. ;) And actually, it might be best to use mergesort since the entries are likely to be sorted. This patches changes a meaningless variable name, adds a auxiliary comparaison function (since strcmp doesn't take **char pointers), and removes extra return's to leave just one at the end. A. --bGR76rFJjkSxVeRa Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch1 Content-Transfer-Encoding: quoted-printable Index: Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/lib/libdisk/Makefile,v retrieving revision 1.27.2.5 diff -u -r1.27.2.5 Makefile --- Makefile 18 Sep 2001 06:47:30 -0000 1.27.2.5 +++ Makefile 22 Dec 2001 23:58:22 -0000 @@ -6,7 +6,7 @@ INCS=3D libdisk.h =20 # Remove KERN_DISKS_BROKEN when kern.disks sysctl returns disks in sorted = order -CFLAGS+=3D -Wall -DKERN_DISKS_BROKEN +CFLAGS+=3D -Wall .if ${MACHINE} =3D=3D "pc98" CFLAGS+=3D -DPC98 .endif Index: disk.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/lib/libdisk/disk.c,v retrieving revision 1.50.2.14 diff -u -r1.50.2.14 disk.c --- disk.c 18 Sep 2001 06:47:30 -0000 1.50.2.14 +++ disk.c 23 Dec 2001 00:43:01 -0000 @@ -483,10 +483,18 @@ static char * device_list[] =3D {"aacd", "ad", "da", "afd", "fla", "idad",= "mlxd", "amrd", "twed", "ar", "fd", 0}; #endif =20 +int qstrcmp(const void* a, const void* b) { + + char *str1 =3D *(char**)a; + char *str2 =3D *(char**)b; + return strcmp(str1, str2); + +} + char ** Disk_Names() { - int i,j,k; + int i,j,disk_cnt; char disk[25]; char diskname[25]; struct stat st; @@ -506,14 +514,16 @@ error =3D sysctlbyname("kern.disks", disklist, &listsize, NULL, 0); if (error)=20 return NULL; - k =3D 0; - for (dp =3D disks; ((*dp =3D strsep(&disklist, " ")) !=3D NULL) && k = < MAX_NO_DISKS; k++, dp++); - return disks; - } + disk_cnt =3D 0; + for (dp =3D disks; ((*dp =3D strsep(&disklist, " ")) !=3D NULL) &&=20 + disk_cnt < MAX_NO_DISKS; disk_cnt++, dp++); + } else { warn("kern.disks sysctl not available"); #endif - k =3D 0; + disk_cnt =3D 0; for (j =3D 0; device_list[j]; j++) { + if(disk_cnt >=3D MAX_NO_DISKS) + break; for (i =3D 0; i < MAX_NO_DISKS; i++) { sprintf(diskname, "%s%d", device_list[j], i); sprintf(disk, _PATH_DEV"%s", diskname); @@ -529,12 +539,17 @@ continue; } close(fd); - disks[k++] =3D strdup(diskname); - if(k =3D=3D MAX_NO_DISKS) - return disks; + disks[disk_cnt++] =3D strdup(diskname); + if(disk_cnt >=3D MAX_NO_DISKS) + break; } } - return disks; +#if !defined(PC98) && !defined(KERN_DISKS_BROKEN) + } +#endif + qsort(disks, disk_cnt, sizeof(char*), qstrcmp); + =20 + return disks; } =20 #ifdef PC98 --bGR76rFJjkSxVeRa-- --7uYPyRQQ5N0D02nI 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 iEYEARECAAYFAjwlK1gACgkQttcWHAnWiGcJjACgh5WL5wD85/hyrMCIzYBl26xI g9QAnA2E4wU1jxvU/lVCG43UbfhP24PX =S4yR -----END PGP SIGNATURE----- --7uYPyRQQ5N0D02nI-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message