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
[-- Attachment #1 --] Yeah, as soon as I realized wht was going on (and giving me the warning), I realized how problemeatic this structure is. I also took a look at the commit, 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 solution would be to define all the elements in the structs to datatypes that 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 way to get this info without causing a program to break. Anyway, the commit 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: > > > >> about if needed. The current kinfo_proc is now actually worse than before, > >> 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 you that > >> proc chagned as they did in the past. Of course, a better way of doing this > > > > Things in the middle must not change. They must be initialized with whatever > > 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. struct > > priority can't be used in struct rusage anyway, since it is a kernel struct. > > Well, it gets more tricky. I've been playing with bumping MAXCOMLEN to 19 (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. > > > Bruce > > -- > > 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/ > [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6kvxuERViMObJ880RARlHAKDF2NMJ16KPsjlVUKOlCiVYC1lAugCeNw++ 7VLIDjDQ8kOnVRqFr4jR79o= =aX9S -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010220182326.A95303>