From owner-freebsd-alpha Mon Mar 26 16: 9:38 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 95EC637B719; Mon, 26 Mar 2001 16:09:35 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2R08vE02662; Mon, 26 Mar 2001 16:08:57 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200103270008.f2R08vE02662@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: Poul-Henning Kamp , John Baldwin , leclercn@videotron.ca, freebsd-alpha@FreeBSD.org Subject: Re: dev_t size mismatch kernel / userland In-reply-to: Your message of "Tue, 27 Mar 2001 09:33:27 +0930." <20010327093327.A40349@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Mar 2001 16:08:57 -0800 From: Mike Smith Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> I'm new to this subject, so please fill me in: just what in the > >> (kernel) dev_t do you want to export to userland ? > > > > Nothing. Greg just leaks a dev_t in a structure exchanged between > > userland and the kernel, and this bit because dev_t is a different > > size between the two on the Alpha; the right fix is simply to not > > abuse this structure like this. > > You're missing a number of things here. If a dev_t is defined in > userland, it should be the same size as in the kernel. The current > situation is obviously a bug. It's certainly open to discussion > whether the dev_t definition in userland gets removed or fixed. Er, no, it's not a bug. dev_t is expected to be one thing in userland, and quite another in the kernel; the assumption used to be that the two were the same; now they are not. > The other issue is that exporting expurgated versions of kernel > structures is expensive. We've been exporting the unexpurgated > versions for years elsewhere, for example--see the proc size mismatch > messages from ps(1). That got fixed, not because it was "unclean", > but because it was a bloody nuisance. Yes, it's "clean" not to export > mutexes and dev_ts and friends, but it requires a fair amount of code > to do it, and it requires two structures which need to be kept in > sync. Exporting them doesn't do any harm that I can see. I don't > think that it's self-evident that you need to go to this much trouble. You basically shoot your own argument dead here. Don't export private data structures to userland. End of story. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message