Date: Tue, 20 Feb 2001 18:23:27 -0500 From: Coleman Kane <cokane@micro.ti.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Bruce Evans <bde@zeta.org.au>, Poul-Henning Kamp <phk@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, "Pierre Y. Dampure" <pierre.dampure@westmarsh.com> Subject: Re: cvs commit: src/sys/sys user.h Message-ID: <20010220182326.A95303@cokane.yi.org> In-Reply-To: <XFMail.010220024811.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Tue, Feb 20, 2001 at 05:48:34AM -0500 References: <Pine.BSF.4.21.0102202029580.19282-100000@besplex.bde.org> <XFMail.010220024811.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yeah, as soon as I realized wht was going on (and giving me the warning), I= =20 realized how problemeatic this structure is. I also took a look at the comm= it, and saw the addition was in the top of it. Well, since this is -CURRENT, we= are supposed to expect breakages like this. Basically, I think a nice temporary= =20 solution would be to define all the elements in the structs to datatypes th= at have static datasizes where we can. Rather than simply int, use u_int32 or whatever is necessary. Of course, it would be optimal to actually have a=20 way to get this info without causing a program to break. Anyway, the commit= =20 seemed to be for an extra variable that probably should be at the top of the kinfo_struct. In the future, it would be advantageous to add variables that describe new info about the process at the end, above the empty space. There has to be a nicer way to implement this, though. John Baldwin had the audacity to say: > On 20-Feb-01 Bruce Evans wrote: > > On Mon, 19 Feb 2001, John Baldwin wrote: > >=20 > >> about if needed. The current kinfo_proc is now actually worse than be= fore, > >> because if something changes in teh middle, then all the programs such= as > >> ps(1), top(1) etc. just misparse the information instead of telling yo= u that > >> proc chagned as they did in the past. Of course, a better way of doin= g this > >=20 > > Things in the middle must not change. They must be initialized with wh= atever > > the used to be, or with dummy values if that is harmless. There would = have > > been no problems if this rule were followed for the priority fields. s= truct > > priority can't be used in struct rusage anyway, since it is a kernel st= ruct. >=20 > Well, it gets more tricky. I've been playing with bumping MAXCOMLEN to 1= 9 (so > it uses a total of 20 rather than 17 chars, which is 32-bit aligned) which > results in expanding teh size of a structure in the middle of kinfo_proc,= which > the current kinfo_proc scheme cannot handle. >=20 > > Bruce >=20 > --=20 >=20 > John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >=20 --ibTvN161/egqYuK8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6kvxuERViMObJ880RARlHAKDF2NMJ16KPsjlVUKOlCiVYC1lAugCeNw++ 7VLIDjDQ8kOnVRqFr4jR79o= =aX9S -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010220182326.A95303>