Date: Fri, 04 Aug 2006 11:49:15 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Olivier Nicole <on@cs.ait.ac.th> Cc: freebsd-questions@freebsd.org, freebsd@hub.org Subject: Re: Stand up and be counted - BSDStats Project Message-ID: <44D3262B.2000400@infracaninophile.co.uk> In-Reply-To: <200608040314.k743EBK6050609@banyan.cs.ait.ac.th> References: <20060803180553.B6529@ganymede.hub.org> <200608040314.k743EBK6050609@banyan.cs.ait.ac.th>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD175CCA8747748C710DD8B16
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Olivier Nicole wrote:
>> pciconf -lv needs to be parsed, this being the hard step, into a strin=
g=20
>> that can be sent via HTTP ... this is the hard part because it has to =
be=20
>> done as/in a shell script ... anyone out there *really* good at shell =
>> programming?
>=20
> Why not doing the parsing on the server?
>=20
> Is there a limit on the size of an HTTP GET request? If not, the
> output of pciconf -v can fit in one single request, done.
>=20
> And limiting the number of requests, you also limit the amount of data
> xfered.
>=20
> I'd also go for:
>=20
> pciconf -l | sed s/\ /+/g | sed s/\ /%09/g| sed s/@/%40/g | sed s/:/%=
3a/g| sed s/=3D/%3d/g
>=20
> and you get lines like:
>=20
> hostb0%40pci0%3a0%3a0%3a%09class%3d0x060000+card%3d0x341a8086+chip%3d0x=
254c8086+rev%3d0x01+hdr%3d0x00
> none0%40pci0%3a0%3a1%3a%09class%3d0xff0000+card%3d0x341a8086+chip%3d0x2=
5418086+rev%3d0x01+hdr%3d0x00
>=20
> That are almost completely URL encoded. Remains to replace the newline
> into %0d, and you are done. Result is one line that is around 2000
> characters.
This is cool and all, but why are the concentration solely on PCI devices=
?
pciconf output doesn't tell you directly what CPUs are in the system or e=
ven
how many there are. It doesn't tell you exactly what sort of memory or d=
isk
drives the system uses -- all of which would be important information tha=
t
might just persuade hardware manufacturers to provide more FreeBSD suppor=
t.
Surely a condensed version of /var/run/dmesg.boot is more to the point.
It's not just about how many machines there are that might use a particul=
ar
manufacturer's devices either, it's about how much money the users of
those machines are prepared to spend. For instance, I could see that a
manufacturer of, say, RAID controllers might well be more interested in
providing FreeBSD support if they knew there was a pent up demand for usi=
ng
their models in top of the line servers rather than the same number of us=
es
based on cheaper, small scale kit. I could take two identical motherboar=
ds
stick 1GB of RAM, a single 40GB IDE drive and a low-spec single core proc=
essor
in one, and in the other I could have two dual core top of the range proc=
essors,
8GB ECC RAM and a terabyte of storage using 15k rpm SAS drives. pciconf
probably wouldn't distinguish between those two specifications.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enigD175CCA8747748C710DD8B16
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE0yY08Mjk52CukIwRCFmTAJ9VwJ8FFmFYDAiLlYv9Hlsz/y3hHgCcDx2d
TLREbjQE4sXPwFuH1YA5O34=
=VmKf
-----END PGP SIGNATURE-----
--------------enigD175CCA8747748C710DD8B16--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44D3262B.2000400>