From owner-freebsd-arch Sun Jul 16 0:28:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D846737B709; Sun, 16 Jul 2000 00:28:29 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sun, 16 Jul 2000 03:28:28 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Warner Losh Cc: freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS In-Reply-To: <200007160535.XAA50733@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 15 Jul 2000, Warner Losh wrote: > : Why? It's got exactly the same considerations as the "true" root being > : able to mount(2) things into a jail or mknod(2). > > You shouldn't be able to mount thinks in jail or mknod. While in > jail, you cannot do a mknod right now. While in jail, you can't do a > mount. > > Creating holes in this scheme makes me extremely nervous. Exactly! The same permissions would apply to this form of symlink as those which apply to mknod and mount in jails. > : > Also, you really don't want too many devices in a jail's /dev tree. > : > You really wouldn't want devfs for jail unless you could limit it > : > severely. And that's going to be hard to write, I think. > : > : But you could create multiple mounts (instances) of devfs which each > : contain a specific subset of the devfs proper and do the "symlink > : breakout" accordingly :) An aspect of jail classes, if you will. > > Why bother with a symlink? Why not have a reference to the real > dev_t? The dev_t of what, exactly? > Warner -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 0:41:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id AAC7137B546; Sun, 16 Jul 2000 00:40:55 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id BAA74519; Sun, 16 Jul 2000 01:40:54 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id BAA51827; Sun, 16 Jul 2000 01:40:34 -0600 (MDT) Message-Id: <200007160740.BAA51827@harmony.village.org> To: Brian Fundakowski Feldman Subject: Re: SysctlFS Cc: freebsd-arch@FreeBSD.org In-reply-to: Your message of "Sun, 16 Jul 2000 03:28:28 EDT." References: Date: Sun, 16 Jul 2000 01:40:34 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Brian Fundakowski Feldman writes: : On Sat, 15 Jul 2000, Warner Losh wrote: : : > : Why? It's got exactly the same considerations as the "true" root being : > : able to mount(2) things into a jail or mknod(2). : > : > You shouldn't be able to mount thinks in jail or mknod. While in : > jail, you cannot do a mknod right now. While in jail, you can't do a : > mount. : > : > Creating holes in this scheme makes me extremely nervous. : : Exactly! The same permissions would apply to this form of symlink : as those which apply to mknod and mount in jails. But this sort of thing is potentially worse. If you can follow the symlink out of jail, can you use it to get to other files? The only way that device nodes exist in the jail now is if the jailors create them for the Jail. Ditto with mount points. Ditto with this. I'm sure that any sort of automatic adding of device nodes to a jail'd process' space is wrong by default. All things that aren't explicitly permitted are forbidden. : > : > Also, you really don't want too many devices in a jail's /dev tree. : > : > You really wouldn't want devfs for jail unless you could limit it : > : > severely. And that's going to be hard to write, I think. : > : : > : But you could create multiple mounts (instances) of devfs which each : > : contain a specific subset of the devfs proper and do the "symlink : > : breakout" accordingly :) An aspect of jail classes, if you will. : > : > Why bother with a symlink? Why not have a reference to the real : > dev_t? : : The dev_t of what, exactly? The device that the jailed process can access. Right now we put the dev_t in the hierarchy of the jailed process, which is the userland dev_t. With a devfs implementation, you could put the kerneland dev_t into the filesystem generally. If you do that, then you'll need to do that in jail as well. If you don't, mknod is suffient for jailed processes, plus maybe with a major number lookup routine (kernel, tell me what the major number for wd). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 0:49: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.20.139.104]) by hub.freebsd.org (Postfix) with ESMTP id 1092D37B6F3; Sun, 16 Jul 2000 00:49:07 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.9.3/8.9.3) with ESMTP id AAA09980; Sun, 16 Jul 2000 00:49:44 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Sun, 16 Jul 2000 00:49:43 -0700 (PDT) From: Kelly Yancey To: Julian Elischer Cc: Robert Watson , Dan Nelson , Warner Losh , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS In-Reply-To: <397034E4.794BDF32@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 15 Jul 2000, Julian Elischer wrote: > Kelly Yancey wrote: > > > > On Sat, 15 Jul 2000, Robert Watson wrote: > > > > > > > Maybe I am missing something obvious, but wouldn't a mount option to > > automatically export a given filesystem to all jails do the trick? Fundamental > > filesystems like procfs and devfs would typically be mounted with the option, > > while others were left to per-jail individual mounts. > > That is, of course, assuming we had room for more MNT_* flags. > > > jails are not 'mounted so there is no specific 'moment' > when you should 'make your automatic mounts. > anyhow you may have 1000 jails set up on your filesystems > do you want to see 2000 filesystems in your mount list? > I didn't mean when you mounted the jail, but rather when you mounted the filesystem in question (i.e. /dev or /proc). The mount flag would be used to indicate that is mount is to transcend jails. In other words, when building a list of the current mount points inside a jail, mount with this flag would always be included. It is arguably a hack, but I don't see why it wouldn't work. Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 0:53:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id EF14A37B5D1; Sun, 16 Jul 2000 00:53:17 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id BAA74563; Sun, 16 Jul 2000 01:53:15 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id BAA52125; Sun, 16 Jul 2000 01:52:55 -0600 (MDT) Message-Id: <200007160752.BAA52125@harmony.village.org> To: Kelly Yancey Subject: Re: SysctlFS Cc: Julian Elischer , Robert Watson , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Sun, 16 Jul 2000 00:49:43 PDT." References: Date: Sun, 16 Jul 2000 01:52:55 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Kelly Yancey writes: : I didn't mean when you mounted the jail, but rather when you mounted the : filesystem in question (i.e. /dev or /proc). The mount flag would be used to : indicate that is mount is to transcend jails. In other words, when building a : list of the current mount points inside a jail, mount with this flag would : always be included. It is arguably a hack, but I don't see why it wouldn't : work. You certainly don't want to do that for /dev in jails. The whole point of jails is that you can give them access to a small subset of devices that are "safe". Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 1:24:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 7451037B6DB; Sun, 16 Jul 2000 01:24:36 -0700 (PDT) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 53D1EDE3; Sun, 16 Jul 2000 01:24:34 -0700 (PDT) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id BAA17605; Sun, 16 Jul 2000 01:24:32 -0700 (PDT) Message-ID: <3971713D.AF57BB53@cup.hp.com> Date: Sun, 16 Jul 2000 01:24:29 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Greg Lehey Cc: Alfred Perlstein , arch@FreeBSD.ORG, marcel@FreeBSD.ORG Subject: Re: I'm fixing the build/install kernel target References: <20000714165105.O25571@fw.wintelcom.net> <20000714172250.P25571@fw.wintelcom.net> <20000716135232.Q57098@wantadilla.lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > > Here's what I think would make sense: > > 1. Allow "make buildkernel" and "make installkernel" in /usr/src with > no options. The results should be identical with the "make all" > and "make install" in /usr/src/sys/compile/MYKERNEL, where > MYKERNEL is the name of the currently running kernel. The rule in > /usr/src can get the name from uname(1). I don't think we should do this. Having a default of GENERIC, optionally overridable by the user, is more "stable" then trying uname. Especially in the light of upgrades where GENERIC is guaranteed to build, this makes sense. > 2. Call the resultant kernel "kernel", not "MYKERNEL". This is what > we're used to, and peter recently went to some trouble to remove > arbitrary kernel names. Agreed. > 3. Put the build directory in the /usr/obj hierarchy, not the > /usr/src/sys/compile hierarchy. That would (help) enable > read-only /usr/src. Agreed. The above implies, IMO, that we don't add support for installing multiple kernels (and their corresponding modules, however we may want to do that). -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 1:48:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 50BE337B6AB; Sun, 16 Jul 2000 01:48:25 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id EAA27518; Sun, 16 Jul 2000 04:48:16 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 16 Jul 2000 04:48:16 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Warner Losh Cc: Kelly Yancey , Julian Elischer , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS In-Reply-To: <200007160752.BAA52125@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You certainly don't want to do that for /dev in jails. The whole > point of jails is that you can give them access to a small subset of > devices that are "safe". So really, whenever I hear discussion of jail/chroot and synthetic system-centric file systems, my immediate responses are: 1) Accept the multiple-mounting, and just make sure that our mount mechanism is scalable (avoid those linear joints down mount lists, etc) 2) Avoid needing to have additional mounts on the jail (reduce dependence on procfs, do not introduce new dependence on procfs) Right now, you can almost completely run without procfs in jail(). Chris Costello even has a killall rewritten to use the pseudo-kvm/sysctl interface. Presumably some debugging dependencies remain. Right now we also certainly don't need a sysctlfs, which while possibly pretty and elegant, is certainly less scalable than just sysctl(). This leaves devfs, and if the mount system is scalable enough (currently isn't, I believe), I don't mind this. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 3:29:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (beachbum.freebsd.dk [212.242.32.0]) by hub.freebsd.org (Postfix) with ESMTP id 7DF3C37B7CE; Sun, 16 Jul 2000 03:29:31 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id MAA02367; Sun, 16 Jul 2000 12:29:27 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Robert Watson Cc: Warner Losh , Kelly Yancey , Julian Elischer , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: DEVFS, the complete picture (Was: Re: SysctlFS) In-reply-to: Your message of "Sun, 16 Jul 2000 04:48:16 EDT." Date: Sun, 16 Jul 2000 12:29:27 +0200 Message-ID: <2365.963743367@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, now I finally have time to sit down and write an email with the complete picture about devfs. For a moment, disregard jails and rootmounts and let us just look at cloning. Cloning means that a device driver doesn't have to call make_dev() on all potential instances up front. This makes most difference for pseudo-devices, tun, ppp, slip, pty, md bpf and so on, but other "actual" drivers like fd could use it as well to avoid calling make_dev() for every conceiveable format of floppydisk. Implementing cloning without devfs would be a gross hack: we would have to magically notice that /dev was searched and nothing found, and I think we might just as well forget everything about that idea. Implementing cloning with devfs is simple: Device-drivers can call devfs during their initialization and register a "clone()" function with devfs. (They obviously have to deregister it again at dettach time). When devfs::VOP_LOOKUP() fails to find the name it is being told to look for, it will call all registered clone() routines successively with the sought after name as argument. Each driver clone routine examine the name, and if it can instantiate a device of that name, it does so with make_dev() and return EEXISTS. If it cannot it returns 0. If it can determine for good that the name should not exist at this time it returns ENOENT; If a clone routine return EEXISTS, devfs::VOP_LOOKUP() immediately retries the lookup, and returns the result. If a clone routine returns ENOENT, devfs::VOP_LOOKUP() fails with ENOENT; When a clone routine returns 0, devfs::VOP_LOOKUP() calls the next clone routine in turn. If when all clone routines have been called none of them have instantiated, devfs::VOP_LOOKUP() returns ENOENT; The dev_t's created this way at not special in any way, all normal rules and rights apply. The only thing special about this is the "lazy creation" of dev_t's. Next, let us look at the rootfs: Today when we boot a FreeBSD system, various magic code finds and mounts a root filesystem from which we execute /sbin/init (and the rest becomes history). A part of this h0h0magic, is to take a device name, and come up with a vnode from which we can mount it, despite the fact that we have no filesystems mounted which can instantiate that vnode. Rather hackish, all in all. Other magic code will do similar gyrations to mount a NFS root filesystem. This obviously is a chicken and egg issue, and there are probably no solution which is universally acceptable. My personal preference is somewhat in the direction of what AIX have done, but with some slight modifications: Kernel initializes, probes devices and all that. Kernel mounts a devfs instance on / Kernel mounts a preloaded (or compiled in) md(4) instance in /bootfs Kernel executes /bootfs/init /bootfs/init examines the environment to find the kind of desired root filesystem. nfs: /bootfs/init will initialize a network interface (using DHCP for instance) and union mount (not unionfs!) the root filesystem on / ufs: /bootfs/init will execute "/bootfs/fsck -p $device", and afterwards unionmount (still not unionfs!) the device on / others: Whatever is needed. After mounting the desired root filesystem, /bootfs/init does an execl("/sbin/init", "/sbin/init", 0); so that the "real" init(8) is started as pid==1 as required. I see many advantages to this scheme, the main thing is that a lot of h0h0magic code moves from the kernel into userland. The /bootfs md(4) instance can be kept around, it will be very small, but it can also be unmounted and if our VM system is taught how to, the RAM can be recycled. This scheme will also take all the pain out of things like raid-5 rootfs: No more kernel h0h0magic code needed, just add the vinum program to /bootfs and DTRT. /bootfs/init could conveniently be a shell script btw. Finally, jails: The only reason there could ever be to mount a devfs in a jail partition is to get access to the cloning facility, mainly for ptys. For the /dev/null, /dev/zero etc cases, a good oldfashioned mknod(8) will do just fine. Remember: the main reason for devfs is to cater for dynamic devices, the main thing we don't want to see pop up in jails is dynamic devices. So the devfs vs jail issue almost entirely boils down to "what do we do about ptys in jails" and considering that it actually works now in "the good old way", I frankly can't see much reason to not just continue that way. Few jails are pty intensive anyway. Summary: 1. Forget about jails in the context of devfs, we don't need it. 2. We can argue if we should unionmount the "real root" over a devfs, or if we should mount devfs on /dev. Both arguments have some amount of merit: The former is cleaner, the latter is more like it used to be. 3. Cloning while not strictly a must, is highly desireable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 8:38:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id C592737B585; Sun, 16 Jul 2000 08:38:20 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id JAA11844; Sun, 16 Jul 2000 09:35:45 -0600 (MDT) Message-Id: <200007161535.JAA11844@berserker.bsdi.com> To: Poul-Henning Kamp Cc: Robert Watson , Warner Losh , Kelly Yancey , Julian Elischer , Dan Nelson , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) From: Chuck Paterson Date: Sun, 16 Jul 2000 09:35:45 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the context of cloning as you describe it how would system administrators control access permissions and the actual names which get created? Chuck Poul-Henning Kamp wrote on: Sun, 16 Jul 2000 12:29:27 +0200 } }OK, now I finally have time to sit down and write an email with the }complete picture about devfs. } }For a moment, disregard jails and rootmounts and let us just look at }cloning. } }Cloning means that a device driver doesn't have to call make_dev() }on all potential instances up front. } }This makes most difference for pseudo-devices, tun, ppp, slip, pty, }md bpf and so on, but other "actual" drivers like fd could use it }as well to avoid calling make_dev() for every conceiveable format }of floppydisk. } }Implementing cloning without devfs would be a gross hack: we would }have to magically notice that /dev was searched and nothing found, }and I think we might just as well forget everything about that idea. } }Implementing cloning with devfs is simple: } } Device-drivers can call devfs during their initialization and } register a "clone()" function with devfs. (They obviously have } to deregister it again at dettach time). } } When devfs::VOP_LOOKUP() fails to find the name it is being told } to look for, it will call all registered clone() routines } successively with the sought after name as argument. } } Each driver clone routine examine the name, and if it can } instantiate a device of that name, it does so with make_dev() } and return EEXISTS. If it cannot it returns 0. If it } can determine for good that the name should not exist at this } time it returns ENOENT; } } If a clone routine return EEXISTS, devfs::VOP_LOOKUP() } immediately retries the lookup, and returns the result. } } If a clone routine returns ENOENT, devfs::VOP_LOOKUP() fails } with ENOENT; } } When a clone routine returns 0, devfs::VOP_LOOKUP() calls the } next clone routine in turn. } } If when all clone routines have been called none of them have } instantiated, devfs::VOP_LOOKUP() returns ENOENT; } } The dev_t's created this way at not special in any way, all normal } rules and rights apply. The only thing special about this is } the "lazy creation" of dev_t's. } }Summary: } }1. Forget about jails in the context of devfs, we don't need it. } }2. We can argue if we should unionmount the "real root" over a } devfs, or if we should mount devfs on /dev. Both arguments } have some amount of merit: The former is cleaner, the latter } is more like it used to be. } }3. Cloning while not strictly a must, is highly desireable. } }-- }Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 }phk@FreeBSD.ORG | TCP/IP since RFC 956 }FreeBSD coreteam member | BSD since 4.3-tahoe }Never attribute to malice what can adequately be explained by incompetence. } } }To Unsubscribe: send mail to majordomo@FreeBSD.org }with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 9:28:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (beachbum.freebsd.dk [212.242.32.0]) by hub.freebsd.org (Postfix) with ESMTP id D4D7C37B9EE; Sun, 16 Jul 2000 09:28:16 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id SAA03950; Sun, 16 Jul 2000 18:28:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Chuck Paterson Cc: Robert Watson , Warner Losh , Kelly Yancey , Julian Elischer , Dan Nelson , Adrian Chadd , freebsd-arch@freebsd.org Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) In-reply-to: Your message of "Sun, 16 Jul 2000 09:35:45 MDT." <200007161535.JAA11844@berserker.bsdi.com> Date: Sun, 16 Jul 2000 18:28:05 +0200 Message-ID: <3948.963764885@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200007161535.JAA11844@berserker.bsdi.com>, Chuck Paterson writes: > > In the context of cloning as you describe it how would >system administrators control access permissions and the actual >names which get created? The devices would get the permissions given in the make_dev() call, ie the "implementing code selected defaults". Sysctls could be used to change this. A devd(8) is probably the correct way to change this. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 13:35:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id 594CF37C7CD for ; Sun, 16 Jul 2000 13:35:04 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 18365 invoked from network); 16 Jul 2000 20:34:57 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 16 Jul 2000 20:34:57 -0000 Message-ID: <39721C71.FD6CB5B2@integratus.com> Date: Sun, 16 Jul 2000 13:34:57 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nik Clayton , freebsd-arch@FreeBSD.ORG Subject: Re: XML configurations References: <20000712144510.A11316@ywing.creative.net.au> <200007130537.WAA29614@apollo.backplane.com> <20000714112117.D17372@ywing.creative.net.au> <20000714053540.A30847@holly.calldei.com> <20000714124327.A64283@mithrandr.moria.org> <396F531F.BBE0D54E@integratus.com> <20000715232447.A21066@kilt.nothing-going-on.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nik Clayton wrote: > > > etc. XML seems like the right answer for this. > > Sort of. You still need to write the DTDs, which is the harder part. The DTD syntax is awfully straight forward, and it is certainly easier to write a DTD (and validating schema) than it is to write a custom parser from scratch (even with lex and yacc). The XML/DTD approach is designed for a constrained problem domain that more closely matches the needs of most configuration files than the generalist approach of lex and yacc. Yes, this statement does mean that I would be willing to contribute some time to getting DTDs written for new file formats. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 13:55:52 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.silyn-tek.de (mout1.silyn-tek.de [194.25.165.69]) by hub.freebsd.org (Postfix) with ESMTP id D1BFE37B6A0 for ; Sun, 16 Jul 2000 13:55:49 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.34] (helo=mx2.silyn-tek.de) by mout1.silyn-tek.de with esmtp (Exim 3.13 #1) id 13DvRz-0004fs-00 for arch@freebsd.org; Sun, 16 Jul 2000 22:55:47 +0200 Received: from p3e9d3899.dip0.t-ipconnect.de ([62.157.56.153] helo=neutron.cichlids.com) by mx2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13DvRx-0004wM-00 for arch@freebsd.org; Sun, 16 Jul 2000 22:55:45 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 897BAAB91 for ; Sun, 16 Jul 2000 22:57:12 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id D625914A62; Sun, 16 Jul 2000 22:55:43 +0200 (CEST) Date: Sun, 16 Jul 2000 22:55:43 +0200 To: arch@freebsd.org Subject: final call: truncate into the base system or not? Message-ID: <20000716225543.A7308@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! How, a final and ready-to-import version of truncate exists: http://people.freebsd.org/~sheldonh/truncate/ Since I can't recall any consensus whether importing or not, but only about implementation details, I'd like to know, what the opinion of _importing_ it into the base system is, _beside_ all implementation details. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 14:25: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id B2D3037B845 for ; Sun, 16 Jul 2000 14:24:59 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.15 #1) id 13Dvtv-000MnH-00; Sun, 16 Jul 2000 23:24:39 +0200 From: Sheldon Hearn To: alex@big.endian.de (Alexander Langer) Cc: arch@FreeBSD.ORG Subject: Re: final call: truncate into the base system or not? In-reply-to: Your message of "Sun, 16 Jul 2000 22:55:43 +0200." <20000716225543.A7308@cichlids.cichlids.com> Date: Sun, 16 Jul 2000 23:24:39 +0200 Message-ID: <87622.963782679@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 16 Jul 2000 22:55:43 +0200, Alexander Langer wrote: > How, a final and ready-to-import version of truncate exists: > > http://people.freebsd.org/~sheldonh/truncate/ > > Since I can't recall any consensus whether importing or not, but only > about implementation details, I'd like to know, what the opinion of > _importing_ it into the base system is, _beside_ all implementation > details. For what it's worth, I've done an about-face on my earlier objection. As explained to me by my mentor, the fact that it won't often be used is outweighed by its usefulness when it _is_ needed and the fact that it's a simple interface to a user-requestable system call with user-visible effects. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 16: 0:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from nothing-going-on.demon.co.uk (unknown [206.79.44.65]) by hub.freebsd.org (Postfix) with ESMTP id CAFE037BF52; Sun, 16 Jul 2000 16:00:00 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) id XAA21142; Sat, 15 Jul 2000 23:24:48 GMT (envelope-from nik) Date: Sat, 15 Jul 2000 23:24:48 +0000 From: Nik Clayton To: Jack Rusher Cc: Neil Blakey-Milner , Chris Costello , Dag-Erling Smorgrav , Adrian Chadd , Matthew Dillon , Andrzej Bialecki , freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS Message-ID: <20000715232447.A21066@kilt.nothing-going-on.org> References: <20000712144510.A11316@ywing.creative.net.au> <200007130537.WAA29614@apollo.backplane.com> <20000714112117.D17372@ywing.creative.net.au> <20000714053540.A30847@holly.calldei.com> <20000714124327.A64283@mithrandr.moria.org> <396F531F.BBE0D54E@integratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <396F531F.BBE0D54E@integratus.com>; from jar@integratus.com on Fri, Jul 14, 2000 at 10:51:27AM -0700 Organization: FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 14, 2000 at 10:51:27AM -0700, Jack Rusher wrote: > Was that motivational enough? Seriously, I'll go looking for > something like this. It would be awfully nice if we started to work > towards a common parser for all configuration files, package files, etc, > etc. XML seems like the right answer for this. Sort of. You still need to write the DTDs, which is the harder part. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jul 16 18:16: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id CEEA737B780 for ; Sun, 16 Jul 2000 18:16:01 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115264>; Mon, 17 Jul 2000 11:15:55 +1000 Content-return: prohibited Date: Mon, 17 Jul 2000 11:15:39 +1000 From: Peter Jeremy Subject: Re: Snapshots in the Fast Filesystem In-reply-to: <200007060342.UAA23667@beastie.mckusick.com>; from mckusick@mckusick.com on Wed, Jul 05, 2000 at 08:42:18PM -0700 To: Kirk McKusick Cc: arch@FreeBSD.ORG Message-Id: <00Jul17.111555est.115264@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <200007060342.UAA23667@beastie.mckusick.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-Jul-05 20:42:18 -0700, Kirk McKusick wrote: >I have completed an initial implementation of snapshots for the >fast filesystem (UFS/FFS). Thank you very much. Having used the snapshot mechanisms in Compaq's AdvFS, I can say that this will be wonderful. Having read the README that you committed, I have a few questions: Disk space overheads: Does creating a snapshot require any additional disk space? I realize that updates will require additional space for the `before' image, but what other metadata overheads are there? Running out of space: Is there any special behaviour when an active FS with one or more snaphsots runs out of disk space? Does the (oldest?) snapshot become invalid to free up space, or is the behaviour indistinguishable from running out of space without snapshots? How does this interact with the UFS minfree boundary? Speed: Is it possible to reduce the time during which FS activity is suspended? As you point out, one use for snapshots is doing point-in- time backups (I do this currently with Compaq Tru64 AdvFS filesystems). From past experience, I've found that Oracle is very sensitive to FS activity blocks - after about 1 sec, Oracle will abort if it's FS activity is blocked. It's possible that other applications have similar behaviour. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 0: 0:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 65F7337B7B4; Mon, 17 Jul 2000 00:00:43 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id QAA22205; Mon, 17 Jul 2000 16:30:38 +0930 (CST) (envelope-from grog) Date: Mon, 17 Jul 2000 16:30:38 +0930 From: Greg Lehey To: arch@FreeBSD.org, smp@FreeBSD.org Subject: Tidying up the interrupt registration process Message-ID: <20000717163038.J26231@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think I now understand how drivers register interrupts with newbus, and it seems that some tidying up is in order. Currently the handlers call BUS_SETUP_INTR with flags intr_type (defined in sys/bus.h): enum intr_type { INTR_TYPE_TTY = 1, INTR_TYPE_BIO = 2, INTR_TYPE_NET = 4, INTR_TYPE_CAM = 8, INTR_TYPE_MISC = 16, INTR_TYPE_FAST = 128 }; At least in nexus_setup_intr (sys/i386/i386/nexus.c), and possibly elsewhere as well, these flags get converted into an interrupt mask and flags for struct intrec, defined in sys/i386/isa/intr_machdep.h: #define INTR_FAST 0x00000001 /* fast interrupt handler */ #define INTR_EXCL 0x00010000 /* exclusive interrupt */ INTR_EXCL comes from the r_flags field in struct resource (sys/rman.h), where it is the complement of RF_SHAREABLE: #define RF_ALLOCATED 0x0001 /* resource has been reserved */ #define RF_ACTIVE 0x0002 /* resource allocation has been activated */ #define RF_SHAREABLE 0x0004 /* resource permits contemporaneous sharing */ #define RF_TIMESHARE 0x0008 /* resource permits time-division sharing */ #define RF_WANTED 0x0010 /* somebody is waiting for this resource */ #define RF_FIRSTSHARE 0x0020 /* first in sharing list */ These flag bits are all lightly used, and there's confusing duplication of functionality. For example, in nexus_setup_intr we have: case (INTR_TYPE_TTY | INTR_TYPE_FAST): mask = &tty_imask; icflags |= INTR_FAST; In sys/pci/pci_compat.c we have if (intflags & INTR_FAST) flags |= INTR_TYPE_FAST; It seems to me that we should define the flags to the *setup_intr functions to match those in struct intrec. Probably the RF_* flags are different enough in purpose that we shouldn't do the same thing there. In addition, these flags will have to change a lot in the change to threaded interrupts. First, I intend to add two additional flags to struct intrec: #define INTR_HEAVY 0x00000002 /* heavyweight interrupt process */ #define INTR_LIGHT 0x00000004 /* light weight interrupt thread */ #define INTR_THREADED (INTR_LIGHT | INTR_HEAVY) /* any kind of interrupt thread */ This will allow us to let traditional interrupts, lightweight threads and heavyweight processes to coexist; when the change is complete, we may be able to let them go away. The INTR_TYPE_TTY and friends are a different issue; at the moment I don't know if they're enough, but probably we should replace them with a process priority. I'd be grateful for any thoughts on these subjects. About fast interrupts, which currently seem to be used only by the sio driver: they perform their entire work before reenabling interrupts, and it's possible that we can keep them like that, though I haven't looked at the code yet. Does anybody know any reason why we should convert them to threaded interrupts? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 1:56: 7 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout2.silyn-tek.de (mout2.silyn-tek.de [194.25.165.70]) by hub.freebsd.org (Postfix) with ESMTP id 5B67737B588; Mon, 17 Jul 2000 01:56:03 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.34] (helo=mx2.silyn-tek.de) by mout2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13E6h0-0004e6-00; Mon, 17 Jul 2000 10:56:02 +0200 Received: from p3e9c116d.dip0.t-ipconnect.de ([62.156.17.109] helo=neutron.cichlids.com) by mx2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13E6gu-00048i-00; Mon, 17 Jul 2000 10:55:57 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id D724BAB91; Mon, 17 Jul 2000 10:57:19 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id BC8EE14A9C; Mon, 17 Jul 2000 10:25:11 +0200 (CEST) Date: Mon, 17 Jul 2000 10:25:11 +0200 To: Alfred Perlstein Cc: Sheldon Hearn , Assar Westerlund , Brian Fundakowski Feldman , arch@FreeBSD.ORG Subject: Re: kernel printf %i? Message-ID: <20000717102511.B5993@cichlids.cichlids.com> References: <5lzonpbc53.fsf@assaris.sics.se> <57067.963303670@axl.ops.uunet.co.za> <20000711013227.P25571@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000711013227.P25571@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Jul 11, 2000 at 01:32:27AM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Alfred Perlstein (bright@wintelcom.net): > > What ANSI standard covers _kernel_ printf()? > POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA is a good argument. I was VERY surprised about having to use %d. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 2: 6:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 5338037B6F0; Mon, 17 Jul 2000 02:06:04 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13E6qO-000P92-00; Mon, 17 Jul 2000 11:05:44 +0200 Date: Mon, 17 Jul 2000 11:05:44 +0200 From: Neil Blakey-Milner To: Matthew Jacob Cc: Marius Bendiksen , Alfred Perlstein , arch@FreeBSD.ORG, marcel@FreeBSD.ORG Subject: Re: I'm fixing the build/install kernel target Message-ID: <20000717110544.A96514@mithrandr.moria.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from mjacob@feral.com on Sat, Jul 15, 2000 at 11:05:38AM -0700 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat 2000-07-15 (11:05), Matthew Jacob wrote: > > I just got through a similar discussion in NetBSD, where somebody wants to > take the probe results of a GENERIC kernel and emit a specific config file for > the hardware configuration just found. > > This would be an *excellent* summer project for a grad student somewhere. > Anyone know someone who's got time on their hands and an itch to do something > valuable like this and generate a paper? options SYSCTL_DEVICES should be able to get this information already, by exporting newbus information to sysctl. My (not-yet-committed) changes to SYSCTL_DEVICES adds irq, drq, iomem, and so forth to the information exported, if that's necessary. What other stuff would be necessary? Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 2:40:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id DAF9C37B7C5; Mon, 17 Jul 2000 02:40:48 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6H9eUv25226; Mon, 17 Jul 2000 02:40:30 -0700 (PDT) Date: Mon, 17 Jul 2000 02:40:30 -0700 From: Alfred Perlstein To: Alexander Langer Cc: Sheldon Hearn , Assar Westerlund , Brian Fundakowski Feldman , arch@FreeBSD.ORG Subject: Re: kernel printf %i? Message-ID: <20000717024029.A24382@fw.wintelcom.net> References: <5lzonpbc53.fsf@assaris.sics.se> <57067.963303670@axl.ops.uunet.co.za> <20000711013227.P25571@fw.wintelcom.net> <20000717102511.B5993@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000717102511.B5993@cichlids.cichlids.com>; from alex@big.endian.de on Mon, Jul 17, 2000 at 10:25:11AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alexander Langer [000717 01:56] wrote: > Thus spake Alfred Perlstein (bright@wintelcom.net): > > > > What ANSI standard covers _kernel_ printf()? > > POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA > > POLA is a good argument. I was VERY surprised about having to use %d. I'm a '%d man' but I had just been reading some C books and all the code was using %i, I was suprised when it didn't work. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 2:44: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout2.silyn-tek.de (mout2.silyn-tek.de [194.25.165.70]) by hub.freebsd.org (Postfix) with ESMTP id 3E2B137B79C; Mon, 17 Jul 2000 02:44:03 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.33] (helo=mx1.silyn-tek.de) by mout2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13E7RS-0004u2-00; Mon, 17 Jul 2000 11:44:02 +0200 Received: from p3e9c116d.dip0.t-ipconnect.de ([62.156.17.109] helo=neutron.cichlids.com) by mx1.silyn-tek.de with esmtp (Exim 3.13 #1) id 13E7RN-00071l-00; Mon, 17 Jul 2000 11:43:57 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id A3DA3AB91; Mon, 17 Jul 2000 11:45:27 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id CDCCF14A62; Mon, 17 Jul 2000 11:43:58 +0200 (CEST) Date: Mon, 17 Jul 2000 11:43:58 +0200 From: Alexander Langer To: Alfred Perlstein Cc: Sheldon Hearn , Assar Westerlund , Brian Fundakowski Feldman , arch@FreeBSD.ORG Subject: Re: kernel printf %i? Message-ID: <20000717114358.A8485@cichlids.cichlids.com> References: <5lzonpbc53.fsf@assaris.sics.se> <57067.963303670@axl.ops.uunet.co.za> <20000711013227.P25571@fw.wintelcom.net> <20000717102511.B5993@cichlids.cichlids.com> <20000717024029.A24382@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000717024029.A24382@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jul 17, 2000 at 02:40:30AM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Alfred Perlstein (bright@wintelcom.net): > I'm a '%d man' but I had just been reading some C books and all the > code was using %i, I was suprised when it didn't work. Same here. After I learned from you IRC folks, %d is the correct param, I was quite surprised, but now it works. Problem is - everyone will run into this problem once :) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 4:56:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from avon.wire.net.au (avon.wire.net.au [203.36.3.8]) by hub.freebsd.org (Postfix) with ESMTP id 6B9B737B8D7; Mon, 17 Jul 2000 04:56:49 -0700 (PDT) (envelope-from davidn@blaze.net.au) Received: from mobile.usn.blaze.net.au (mobile.usn.blaze.net.au [203.17.53.104]) by avon.wire.net.au (8.9.3/8.9.3) with ESMTP id VAA79628; Mon, 17 Jul 2000 21:56:43 +1000 (EST) (envelope-from davidn@blaze.net.au) Date: Sun, 16 Jul 2000 15:32:00 +1000 (EST) From: David Nugent X-Sender: davidn@mobile.mel.ausisp.net Reply-To: davidn@blaze.net.au To: Hajimu UMEMOTO Cc: cvs-committers@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: cvs commit: src/lib/libutil realhostname.c In-Reply-To: <200007141808.LAA07166@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 14 Jul 2000, Hajimu UMEMOTO wrote: > I have a grudge against the shortage of UT_HOSTSIZE. I have a grudge against the only legitmate uses of it; the utmp/wtmp formats. I had a go at fixing it once, but there did not seem a great deal of interest other than minor feedback. It's a difficult matter since fiddling with this messes with fringe portability and defacto BSD practices and standards (not that there really are any over a wider range of UNIXen, which is the real problem). Raw space savings in wtmp by use of a variable length, even text format is surprisingly large, and encapsulating it behind a standard API hides it enough that we should not need to worry about the physical storage mechanism, be it a berkeley db, flat text file, fix or variable length flat record, ldap directory or an sql database. nsswitch.conf might provide a gateway there (is anyone still working on nsswitch for FreeBSD these days?) Considering this is one of the few issues that gets in the way of expanding namespace on UNIX systems (capability of handling a full kerberos name.user@realm or ldap dn cn=davidn,dc=freebsd,dc=org are good examples), I think finally resolving this means that the limitations of UT_*SIZE are well on the way to just going away. The use of these macros elsewhere is - or at least used to be - a conveniently reliable limit. The kernel does impost a limit, but changing that would not be too difficult. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 6:25:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 593D737B958 for ; Mon, 17 Jul 2000 06:25:16 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13EAtW-0000eX-00 for arch@FreeBSD.org; Mon, 17 Jul 2000 15:25:14 +0200 Date: Mon, 17 Jul 2000 15:25:14 +0200 From: Neil Blakey-Milner To: arch@FreeBSD.org Subject: Conditionally removing cosmetic messages for small kernels (PICOBSD). Message-ID: <20000717152514.A2056@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="WIyZ46R2i8wDzkSu" X-Mailer: Mutt 1.0.1i Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Hi, While building a PicoBSD disk for work purposes, I noticed that pcisupport.c was the largest object file sitting there, at 43k. By removing (#ifndef PICOBSD, better names accepted) the cosmetic probe messages, I managed to reduce that to 23k easily enough, buying me a few more executables (and NTFS support, which was why I was building the disk). If I were to do/start the work on the rest of the system, would this be acceptable? Initial patch attached. (There seems to be "quirk" fixes mixed in with the cosmetic stuff, so the patches aren't as clean as they could be.) Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pcisupport.cosmetic.patch" Index: pcisupport.c =================================================================== RCS file: /home/ncvs/src/sys/pci/pcisupport.c,v retrieving revision 1.163 diff -u -r1.163 pcisupport.c --- pcisupport.c 2000/06/09 16:00:28 1.163 +++ pcisupport.c 2000/07/17 13:17:40 @@ -673,6 +673,7 @@ static const char* pcib_match(device_t dev) { +#ifndef PICOBSD switch (pci_get_devid(dev)) { /* Intel -- vendor 0x8086 */ case 0x71818086: @@ -733,6 +734,7 @@ case 0x88811060: return ("UMC UM8881 HB4 486 PCI Chipset"); }; +#endif if (pci_get_class(dev) == PCIC_BRIDGE && pci_get_subclass(dev) == PCIS_BRIDGE_PCI) @@ -832,6 +834,7 @@ { unsigned rev; +#ifndef PICOBSD switch (pci_get_devid(dev)) { case 0x04848086: rev = pci_get_revid(dev); @@ -903,6 +906,7 @@ && pci_get_subclass(dev) == PCIS_BRIDGE_ISA) return ("Cypress 82C693 PCI-ISA bridge"); } +#endif if (pci_get_class(dev) == PCIC_BRIDGE && pci_get_subclass(dev) == PCIS_BRIDGE_ISA) @@ -979,6 +983,7 @@ const char * pci_usb_match(device_t dev) { +#ifndef PICOBSD switch (pci_get_devid(dev)) { /* Intel -- vendor 0x8086 */ @@ -1015,6 +1020,7 @@ case 0x06731095: return ("CMD Tech 673 (USB0673) USB controller"); } +#endif if (pci_get_class(dev) == PCIC_SERIALBUS && pci_get_subclass(dev) == PCIS_SERIALBUS_USB) { @@ -1033,6 +1039,7 @@ pci_ata_match(device_t dev) { +#ifndef PICOBSD switch (pci_get_devid(dev)) { /* Intel -- vendor 0x8086 */ @@ -1093,6 +1100,7 @@ case 0xd5681045: return ("OPTi 82C700 (FireStar) ATA controller(generic mode):"); } +#endif if (pci_get_class(dev) == PCIC_STORAGE && pci_get_subclass(dev) == PCIS_STORAGE_IDE) @@ -1121,6 +1129,7 @@ case 0x12258086: fixbushigh_i1225(dev); return ("Intel 824?? host to PCI bridge"); +#ifndef PICOBSD case 0x71808086: return ("Intel 82443LX (440 LX) host to PCI bridge"); case 0x71908086: @@ -1160,9 +1169,11 @@ return ("Intel 82439TX System controller (MTXC)"); case 0x71138086: return ("Intel 82371AB Power management controller"); +#endif case 0x12378086: fixwsc_natoma(dev); return ("Intel 82440FX (Natoma) PCI and memory controller"); +#ifndef PICOBSD case 0x84c58086: return ("Intel 82453KX/GX (Orion) PCI memory controller"); case 0x71208086: @@ -1301,6 +1312,7 @@ case 0x002c1033: case 0x003b1033: return NULL; +#endif }; if (pci_get_class(dev) == PCIC_BRIDGE @@ -1328,6 +1340,7 @@ const char *vendor, *chip, *type; vendor = chip = type = 0; +#ifndef PICOBSD switch (id & 0xffff) { case 0x003d: vendor = "Real 3D"; @@ -1770,6 +1783,7 @@ sprintf(buf, "%s %s %s", vendor, chip, type); return buf; } +#endif switch (pci_get_class(dev)) { --WIyZ46R2i8wDzkSu-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 6:43: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 2AFB637B98A for ; Mon, 17 Jul 2000 06:42:59 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id PAA02514; Mon, 17 Jul 2000 15:42:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Neil Blakey-Milner Cc: arch@FreeBSD.ORG Subject: Re: Conditionally removing cosmetic messages for small kernels (PICOBSD). In-reply-to: Your message of "Mon, 17 Jul 2000 15:25:14 +0200." <20000717152514.A2056@mithrandr.moria.org> Date: Mon, 17 Jul 2000 15:42:45 +0200 Message-ID: <2512.963841365@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think it should be possible to not spend all that space on text strings. I also think that using a table rather than tons of switch statements make more sense. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 6:55:56 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout2.silyn-tek.de (mout2.silyn-tek.de [194.25.165.70]) by hub.freebsd.org (Postfix) with ESMTP id 0313D37B64D for ; Mon, 17 Jul 2000 06:55:54 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.34] (helo=mx2.silyn-tek.de) by mout2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EBNA-0006HT-00 for arch@freebsd.org; Mon, 17 Jul 2000 15:55:52 +0200 Received: from p3e9c116d.dip0.t-ipconnect.de ([62.156.17.109] helo=neutron.cichlids.com) by mx2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EBN8-0007vB-00 for arch@freebsd.org; Mon, 17 Jul 2000 15:55:50 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 4A5C9AB91 for ; Mon, 17 Jul 2000 15:57:21 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 9BC4214A9C; Mon, 17 Jul 2000 15:55:52 +0200 (CEST) Date: Mon, 17 Jul 2000 15:55:52 +0200 From: Alexander Langer To: arch@freebsd.org Subject: removal of kvtop() on i386 Message-ID: <20000717155552.A19233@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [reposting to -arch, where it is better] Hello! I recently wanted to port the if_ed driver to alpha. FreeBSD/alpha still misses kvtop(), so I implemented it. However, bde told me, that the whole function kvtop() is wrong, since "0" is a legitimate physical address and therefore the panic is misplaced. That means, kvtop() is obsolete. Before I continue porting the driver, I'd like to have this issue resolved. Please take a look at this (kinda old) patch: - Remove pmap_kextract from pmap.h for alpha and add it to pmap.c - remove pmap_kextract from vm_machdep.c for i386 and add it to pmap.c - change all kvtop() to pmap_kextract() in the src. http://people.freebsd.org/~alex/remove-kvtop.diff I received no further comments about this patch from bde, and dillon didn't answer to an email concerning this. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ----- End forwarded message ----- -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 7: 1:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 07EDE37B682 for ; Mon, 17 Jul 2000 07:01:45 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id QAA02654; Mon, 17 Jul 2000 16:01:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alexander Langer Cc: arch@FreeBSD.ORG Subject: Re: removal of kvtop() on i386 In-reply-to: Your message of "Mon, 17 Jul 2000 15:55:52 +0200." <20000717155552.A19233@cichlids.cichlids.com> Date: Mon, 17 Jul 2000 16:01:38 +0200 Message-ID: <2652.963842498@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000717155552.A19233@cichlids.cichlids.com>, Alexander Langer writ es: >[reposting to -arch, where it is better] > >Hello! > >I recently wanted to port the if_ed driver to alpha. >FreeBSD/alpha still misses kvtop(), so I implemented it. > >Please take a look at this (kinda old) patch: > >- Remove pmap_kextract from pmap.h for alpha and add it to pmap.c >- remove pmap_kextract from vm_machdep.c for i386 and add it to pmap.c > >- change all kvtop() to pmap_kextract() in the src. > >http://people.freebsd.org/~alex/remove-kvtop.diff I like it, but I like the name kvtop() better :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 7:43:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 280C037B9CE for ; Mon, 17 Jul 2000 07:43:39 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id IAA22202; Mon, 17 Jul 2000 08:41:00 -0600 (MDT) Message-Id: <200007171441.IAA22202@berserker.bsdi.com> To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: removal of kvtop() on i386 From: Chuck Paterson Date: Mon, 17 Jul 2000 08:41:00 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Has anybody though about how to change this for architectures like Sparc where the whole idea of handing a physical address to the drivers on a bus doesn't apply, and where a unmapping/cache flushing operation must be done at io completion. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 8:45:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3276D37B558 for ; Mon, 17 Jul 2000 08:43:47 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p37-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.38]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id AAA11562; Tue, 18 Jul 2000 00:43:16 +0900 (JST) Message-ID: <397329AA.15B7CEB5@newsguy.com> Date: Tue, 18 Jul 2000 00:43:38 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Sheldon Hearn , Wes Peters , Warner Losh , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Why don't section 4 pages live with their drivers? References: <78679.963388979@axl.ops.uunet.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > > You sure it's worth 1.2MB of repo bloat? > > One tenth of a percent? Couldn't care less. It'll hurt people > cvsupping or ctming over slow lines, but not much more than, say, a > gcc or perl upgrade or a new branch tag. Or the crypto "merge"... :-( -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@a.crazy.bsdconspiracy.net "There is no spoon." -- Kiki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 8:55:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id E19BE37BC9A; Mon, 17 Jul 2000 08:54:00 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id JAA24715; Mon, 17 Jul 2000 09:53:50 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200007171553.JAA24715@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: Greg Lehey Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process In-reply-to: Your message of "Mon, 17 Jul 2000 16:30:38 +0930." <20000717163038.J26231@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jul 2000 09:53:49 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > I think I now understand how drivers register interrupts with newbus, > and it seems that some tidying up is in order. > ... > About fast interrupts, which currently seem to be used only by the sio > driver: they perform their entire work before reenabling interrupts, > and it's possible that we can keep them like that, though I haven't > looked at the code yet. Does anybody know any reason why we should > convert them to threaded interrupts? Its been quite awhile since I looked at this code, so forgive any inaccuracies on my part... I believe the sio FAST_INTR gets away with "they perform their entire work before reenabling interrupts" because it defers much of the work to the tty soft INTR level. In the ISR itself, it drains the hardware ASAP, then lets the soft INTR process the queues, etc. This method is used to prevent overflowing the sio fifos, which would otherwise occur if the INT were defered till spl() said it could proceed. If the new kernel model allows INTR threads to preempt, I would favor eliminating this sio 'special case', and use high priority for the sio ISR to get the same effect. I am a great fan of ISRs that look something like: sio_intr( struct threadStuff * s ) { ssignal( &(s->intrSem) ); } -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 9:36:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id D7FEE37BA4E for ; Mon, 17 Jul 2000 09:36:16 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id LAA73513 for arch@freebsd.org; Mon, 17 Jul 2000 11:41:02 -0500 (CDT) (envelope-from jlemon) Date: Mon, 17 Jul 2000 11:41:02 -0500 From: Jonathan Lemon To: arch@freebsd.org Subject: kqueue API change Message-ID: <20000717114102.E67727@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After some feedback and real real world experience with kqueue, I'd like to make some small changes to the API in order to clean it up. The parameters to the system call will be changed from: kevent(int kq, int nchanges, struct kevent **changelist, int nevents, struct kevent *eventlist, struct timespec *timeout) to: int kevent(int kq, const struct kevent *changelist, int nchanges, struct kevent *eventlist, int nevents, const struct timespec *timeout) There are 3 changes: - swap the argment order so it is (buffer, count) in order to match almost every other system call (thanks to green for pointing this out) - addition of `const' to the parameters to make it clear that they are not changed by the kernel - change the `array of pointers to structs' to a flat array of structures. The latter change will allow the elimination of one layer of copyin() calls in the kernel, and will probably make the API easier to understand for new users. By eliminating the indirection, the cache footprint is also reduced as well. The only possible downside that I can see is that the input array now must be contiguous, but because it can also be reaused as the output list, this seems to be a minor point. I'd like to get this change in as soon as possible so it will be contained in the 4.1-release. Because kq has not appeared in an official release yet, I don't have too much concern about breaking compatability at this point, and I'll take care up updating the two ports in the tree that currently use it. (l0pht-watch and py-kqueue). -- Jonathan (If you've sent me mail in the last 3-4 weeks and haven't gotten a response, please resend it. I've just returned from an extended business trip + vacation, and may have been a little too liberal with the `delete' key in cleaning up my mailbox) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 9:40:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout2.silyn-tek.de (mout2.silyn-tek.de [194.25.165.70]) by hub.freebsd.org (Postfix) with ESMTP id D5E2D37B9B7; Mon, 17 Jul 2000 09:40:15 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.34] (helo=mx2.silyn-tek.de) by mout2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EDvd-0007y8-00; Mon, 17 Jul 2000 18:39:37 +0200 Received: from p3e9c116d.dip0.t-ipconnect.de ([62.156.17.109] helo=neutron.cichlids.com) by mx2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EDvY-0003PQ-00; Mon, 17 Jul 2000 18:39:33 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id D0345AB91; Mon, 17 Jul 2000 18:40:52 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 8627C14A62; Mon, 17 Jul 2000 18:39:18 +0200 (CEST) Date: Mon, 17 Jul 2000 18:39:18 +0200 To: James Howard Cc: Ben Smithurst , Brian Somers , freebsd-hackers@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: /etc/security -> /etc/periodic/security ? Message-ID: <20000717183918.A26484@cichlids.cichlids.com> References: <20000713132845.C48641@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from howardjp@glue.umd.edu on Thu, Jul 13, 2000 at 04:48:52PM -0400 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake James Howard (howardjp@glue.umd.edu): > fairings? Why does it matter what color the bikeshed is? What does What is this thing with the bikesheds??? It appears on every place I am, on IRC, now here. As a non-native English-speaker, I'd like to know what's up with the poor bikesheds. The poor ones :-( Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 9:42:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.silyn-tek.de (mout1.silyn-tek.de [194.25.165.69]) by hub.freebsd.org (Postfix) with ESMTP id 2591D37BA9A for ; Mon, 17 Jul 2000 09:42:14 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.33] (helo=mx1.silyn-tek.de) by mout1.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EDy4-00014Y-00; Mon, 17 Jul 2000 18:42:08 +0200 Received: from p3e9c116d.dip0.t-ipconnect.de ([62.156.17.109] helo=neutron.cichlids.com) by mx1.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EDy2-00052r-00; Mon, 17 Jul 2000 18:42:07 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 8F71CAB91; Mon, 17 Jul 2000 18:43:37 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 69C9714A62; Mon, 17 Jul 2000 18:42:08 +0200 (CEST) Date: Mon, 17 Jul 2000 18:42:08 +0200 To: Chuck Paterson Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: removal of kvtop() on i386 Message-ID: <20000717184208.B26484@cichlids.cichlids.com> References: <200007171441.IAA22202@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007171441.IAA22202@berserker.bsdi.com>; from cp@bsdi.com on Mon, Jul 17, 2000 at 08:41:00AM -0600 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Chuck Paterson (cp@bsdi.com): > Has anybody though about how to change this for > architectures like Sparc where the whole idea of handing > a physical address to the drivers on a bus doesn't apply, and > where a unmapping/cache flushing operation must be done > at io completion. Uhm. Is that support for removing kvtop(), against removing kvtop() or just a questions beside that topic? How do other *BSDs do that? Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 10: 1: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7E9C437B558 for ; Mon, 17 Jul 2000 10:01:00 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6HH0xi06015; Mon, 17 Jul 2000 10:00:59 -0700 (PDT) Date: Mon, 17 Jul 2000 10:00:59 -0700 From: Alfred Perlstein To: Jonathan Lemon Cc: arch@FreeBSD.ORG Subject: Re: kqueue API change Message-ID: <20000717100059.H24382@fw.wintelcom.net> References: <20000717114102.E67727@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000717114102.E67727@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Mon, Jul 17, 2000 at 11:41:02AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jonathan Lemon [000717 09:40] wrote: > > After some feedback and real real world experience with kqueue, > I'd like to make some small changes to the API in order to clean it up. > > The parameters to the system call will be changed from: > > kevent(int kq, int nchanges, struct kevent **changelist, int nevents, > struct kevent *eventlist, struct timespec *timeout) > > to: > > int > kevent(int kq, const struct kevent *changelist, int nchanges, > struct kevent *eventlist, int nevents, > const struct timespec *timeout) > I'd like to get this change in as soon as possible so it will be > contained in the 4.1-release. Because kq has not appeared in an > official release yet, I don't have too much concern about breaking > compatability at this point, and I'll take care up updating the two > ports in the tree that currently use it. (l0pht-watch and py-kqueue). I also think a careful audit of the kernel code for f_type problems needs to be done: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_descrip.c.diff?r1=1.84&r2=1.85 Please post a HEADSUP after you've committed your API changes, I have several important peices of code using the old API. Also, one last change while you're at it, don't make timeout const, do it the right way, make it changeable don't make the same mistake select() did. I would also add a last parameter 'flags' that needs to be zero, so if the 'timeout' issue had come after the change we could have made it an option based on the flags parameter. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 10: 5:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id A547837BBAD; Mon, 17 Jul 2000 10:05:05 -0700 (PDT) (envelope-from jre@iprg.nokia.com) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21292; Mon, 17 Jul 2000 10:05:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA17809; Mon, 17 Jul 2000 10:05:03 -0700 X-Virus-Scanned: Mon, 17 Jul 2000 10:05:03 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from radio.iprg.nokia.com (205.226.1.150, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdH6iIWK; Mon, 17 Jul 2000 10:04:58 PDT Message-ID: <39733CBB.7147BA74@iprg.nokia.com> Date: Mon, 17 Jul 2000 10:04:59 -0700 From: Joe Eykholt Organization: Nokia IPRG X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Passe Cc: Greg Lehey , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process References: <200007171553.JAA24715@Ilsa.StevesCafe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Steve's correct about the fast interrupt being needed to prevent overflow of the serial FIFOs. So, FAST interrupts haven't been blocked by spl (even splhigh) and the lower half of the driver has to disable interrupts in order to blcok the FAST interrupt. Just one more thing to consider: its pretty nice when using a serial console to be able to break into the debugger even when at splhigh(), and the FAST_INTR setup allows this. If serial interrupts were threads, then this probably wouldn't be possible. Solaris 2.5 (and probably the more recent versions also) uses the equivalent of fast interrupts for serial also. Joe Steve Passe wrote: > > Hi, > > > I think I now understand how drivers register interrupts with newbus, > > and it seems that some tidying up is in order. > > ... > > About fast interrupts, which currently seem to be used only by the sio > > driver: they perform their entire work before reenabling interrupts, > > and it's possible that we can keep them like that, though I haven't > > looked at the code yet. Does anybody know any reason why we should > > convert them to threaded interrupts? > > Its been quite awhile since I looked at this code, so forgive any inaccuracies > on my part... I believe the sio FAST_INTR gets away with "they perform their > entire work before reenabling interrupts" because it defers much of the work > to the tty soft INTR level. In the ISR itself, it drains the hardware ASAP, > then lets the soft INTR process the queues, etc. This method is used to > prevent overflowing the sio fifos, which would otherwise occur if the INT were > defered till spl() said it could proceed. If the new kernel model allows > INTR threads to preempt, I would favor eliminating this sio 'special case', > and use high priority for the sio ISR to get the same effect. I am a great > fan of ISRs that look something like: > > sio_intr( struct threadStuff * s ) > { > ssignal( &(s->intrSem) ); > } > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- Joe Eykholt jre@iprg.nokia.com +1 650 625 2041 Nokia Internet Communications http://www.iprg.nokia.com 313 Fairchild Drive, Mountain View, CA 94043 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 10:13:36 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id A2E3937B7F5 for ; Mon, 17 Jul 2000 10:13:29 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id LAA12245; Mon, 17 Jul 2000 11:10:24 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200007171710.LAA12245@pluto.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: alex@big.endian.de (Alexander Langer) Cc: Chuck Paterson , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: removal of kvtop() on i386 In-Reply-To: Your message of "Mon, 17 Jul 2000 18:42:08 +0200." <20000717184208.B26484@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jul 2000 11:11:06 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Thus spake Chuck Paterson (cp@bsdi.com): > >> Has anybody though about how to change this for >> architectures like Sparc where the whole idea of handing >> a physical address to the drivers on a bus doesn't apply, and >> where a unmapping/cache flushing operation must be done >> at io completion. ... >How do other *BSDs do that? Bus DMA. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 10:53:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id DE0FE37BBA1 for ; Mon, 17 Jul 2000 10:53:11 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id LAA23382; Mon, 17 Jul 2000 11:42:38 -0600 (MDT) Message-Id: <200007171742.LAA23382@berserker.bsdi.com> To: alex@big.endian.de (Alexander Langer) Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: removal of kvtop() on i386 From: Chuck Paterson Date: Mon, 17 Jul 2000 11:42:38 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG } }Uhm. Is that support for removing kvtop(), against removing kvtop() }or just a questions beside that topic? } No comment on the actual change. Its more of an observation that this is changing something that is still fundamentally broken. }How do other *BSDs do that? } }Alex }-- }... } }>How do other *BSDs do that? } }Bus DMA. } }-- }Justin } "Bus DMA" == abstracted out. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 10:55: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 261B537BB43; Mon, 17 Jul 2000 10:54:55 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA26902; Mon, 17 Jul 2000 10:54:39 -0700 Date: Mon, 17 Jul 2000 10:54:36 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Neil Blakey-Milner Cc: Marius Bendiksen , Alfred Perlstein , arch@FreeBSD.ORG, marcel@FreeBSD.ORG Subject: Re: I'm fixing the build/install kernel target In-Reply-To: <20000717110544.A96514@mithrandr.moria.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > My (not-yet-committed) changes to SYSCTL_DEVICES adds irq, drq, iomem, > and so forth to the information exported, if that's necessary. > > What other stuff would be necessary? Any other properties that can be attached to that particular device instance. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 11: 1:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 11A3937BA7E; Mon, 17 Jul 2000 11:01:13 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA81199; Mon, 17 Jul 2000 12:01:10 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA62644; Mon, 17 Jul 2000 12:00:45 -0600 (MDT) Message-Id: <200007171800.MAA62644@harmony.village.org> To: alex@big.endian.de (Alexander Langer) Subject: Re: /etc/security -> /etc/periodic/security ? Cc: James Howard , Ben Smithurst , Brian Somers , freebsd-hackers@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 17 Jul 2000 18:39:18 +0200." <20000717183918.A26484@cichlids.cichlids.com> References: <20000717183918.A26484@cichlids.cichlids.com> <20000713132845.C48641@strontium.scientia.demon.co.uk> Date: Mon, 17 Jul 2000 12:00:45 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000717183918.A26484@cichlids.cichlids.com> Alexander Langer writes: : What is this thing with the bikesheds??? Summary: phk sent out a long message about how one can do huge things w/o anybody complaining because they don't feel they are quailified to. One cannot do small things without getting bogged down in details because everybody who wants to make their mark does so there because tehy feel qualified to do so. His example was a bike shed. what color to paint it, where to put it, what architectural details to put on it etc. With all these questions, the bikeshed never got built. warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 11: 5:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id EC46F37BF27 for ; Mon, 17 Jul 2000 11:05:31 -0700 (PDT) (envelope-from mwlucas@blackhelicopters.org) Received: (from mwlucas@localhost) by blackhelicopters.org (8.9.3/8.9.3) id OAA05517; Mon, 17 Jul 2000 14:05:16 -0400 (EDT) (envelope-from mwlucas) From: Michael Lucas Message-Id: <200007171805.OAA05517@blackhelicopters.org> Subject: Bikesheds In-Reply-To: <20000717183918.A26484@cichlids.cichlids.com> from Alexander Langer at "Jul 17, 2000 6:39:18 pm" To: alex@big.endian.de (Alexander Langer) Date: Mon, 17 Jul 2000 14:05:16 -0400 (EDT) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What is this thing with the bikesheds??? > > It appears on every place I am, on IRC, now here. > > As a non-native English-speaker, I'd like to know what's up with the > poor bikesheds. The poor ones :-( Actually, I believe it's a FreeBSDism. You see, when it comes to the advanced topics such as how to redesign the VM subsystem or how to implement DEVFS, there are only a few people who can competently comment. They reach a consensus amongst themselves, and work proceeds apace. When it comes to more basic, general topics, more people can comment. Any competent coder could write code for function X, so every competent coder on the list feels obliged to make comments about function X. Similarly, almost everyone also feels competent to describe the weaknesses in other approaches. The discussion drags, and drags, and drags. It's like construction work. Very few people can build a skyscraper, but anyone can build a bike shed. When someone mentions "painting the bikeshed" it means "we've argued about this long enough, most of the solutions are just fine, will you please just implement one and SHUT UP?" (subject changed so hopefully the search engines will pick it up) ==ml To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 11: 8:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.integratus.com (miami.integratus.com [63.209.2.83]) by hub.freebsd.org (Postfix) with SMTP id DACBB37BB0E for ; Mon, 17 Jul 2000 11:08:20 -0700 (PDT) (envelope-from jar@integratus.com) Received: (qmail 25452 invoked from network); 17 Jul 2000 18:08:18 -0000 Received: from kungfu.integratus.com (HELO integratus.com) (172.20.5.168) by tortuga1.integratus.com with SMTP; 17 Jul 2000 18:08:18 -0000 Message-ID: <39734B92.E2B3B6CE@integratus.com> Date: Mon, 17 Jul 2000 11:08:18 -0700 From: Jack Rusher Organization: Integratus X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Joe Eykholt Cc: Steve Passe , Greg Lehey , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process References: <200007171553.JAA24715@Ilsa.StevesCafe.com> <39733CBB.7147BA74@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Eykholt wrote: > > Just one more thing to consider: its pretty nice when using a serial > console to be able to break into the debugger even when at splhigh(), > and the FAST_INTR setup allows this. If serial interrupts were > threads, then this probably wouldn't be possible. > > Solaris 2.5 (and probably the more recent versions also) uses the > equivalent of fast interrupts for serial also. Solaris (up to 2.8) has fifteen interrupt levels, laid out like this: 1-9: "low" interrupts that are handled by kernel threads 10: "clock" interrupt, which (until 2.8) was used for the clock 11-15: "high" interrupts ...the low interrupts are general device interrupts (SCSI, frame buffer, etc), while the high set are for the serial devices. The low set are all handled by a 1/1 thread/interrupt scheme. Each CPU has a set of 9 interrupt threads waiting around to do the dirty work. This allows multiple CPUs to share the processing burden associated with device I/O. There is one system wide clock thread (until 2.8). The high set are handled in the context of the currently running thread, using the shortest code path they can manage. They did this because of the same overflow/console debugging issues that are currently being discussed here. -- Jack Rusher, Senior Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 11:19:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id C07F037BDA7 for ; Mon, 17 Jul 2000 11:19:22 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id LAA10544; Mon, 17 Jul 2000 11:28:04 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007171828.LAA10544@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alexander Langer Cc: arch@freebsd.org Subject: Re: removal of kvtop() on i386 In-reply-to: Your message of "Mon, 17 Jul 2000 15:55:52 +0200." <20000717155552.A19233@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jul 2000 11:28:03 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [reposting to -arch, where it is better] > > Hello! > > I recently wanted to port the if_ed driver to alpha. > FreeBSD/alpha still misses kvtop(), so I implemented it. The 'ed' driver should be rewritten to use newbus/busspace, at which point kvtop stops being an issue. -- ... 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] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 11:27:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout1.silyn-tek.de (mout1.silyn-tek.de [194.25.165.69]) by hub.freebsd.org (Postfix) with ESMTP id AE02E37BDD9; Mon, 17 Jul 2000 11:27:29 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.34] (helo=mx2.silyn-tek.de) by mout1.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EFbz-00023Y-00; Mon, 17 Jul 2000 20:27:27 +0200 Received: from p3e9c116d.dip0.t-ipconnect.de ([62.156.17.109] helo=neutron.cichlids.com) by mx2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EFbw-0006CD-00; Mon, 17 Jul 2000 20:27:25 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id DC80FAB91; Mon, 17 Jul 2000 20:28:51 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id AF32014A62; Mon, 17 Jul 2000 20:27:22 +0200 (CEST) Date: Mon, 17 Jul 2000 20:27:22 +0200 From: Alexander Langer To: Mike Smith Cc: arch@freebsd.org Subject: Re: removal of kvtop() on i386 Message-ID: <20000717202722.A31370@cichlids.cichlids.com> References: <20000717155552.A19233@cichlids.cichlids.com> <200007171828.LAA10544@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007171828.LAA10544@mass.osd.bsdi.com>; from msmith@freebsd.org on Mon, Jul 17, 2000 at 11:28:03AM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Mike Smith (msmith@freebsd.org): > The 'ed' driver should be rewritten to use newbus/busspace, at which > point kvtop stops being an issue. kvtop() is not only an issue w/ 'ed', but also with other network devices, such as lnc and ie. However, the question is "kvtop", not the ed driver :) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 11:35: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id 3C1D837BB7E for ; Mon, 17 Jul 2000 11:34:43 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id LAA10722; Mon, 17 Jul 2000 11:43:31 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007171843.LAA10722@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alexander Langer Cc: arch@freebsd.org Subject: Re: removal of kvtop() on i386 In-reply-to: Your message of "Mon, 17 Jul 2000 20:27:22 +0200." <20000717202722.A31370@cichlids.cichlids.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jul 2000 11:43:30 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Thus spake Mike Smith (msmith@freebsd.org): > > > The 'ed' driver should be rewritten to use newbus/busspace, at which > > point kvtop stops being an issue. > > kvtop() is not only an issue w/ 'ed', but also with other network > devices, such as lnc and ie. > > However, the question is "kvtop", not the ed driver :) No, the question is the immediate necessity to stop using obsoleted interfaces in device drivers, of which kvotp is just one. -- ... 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] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 11:38:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id 3B0EB37B761 for ; Mon, 17 Jul 2000 11:38:35 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id LAA10760; Mon, 17 Jul 2000 11:47:23 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007171847.LAA10760@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Chuck Paterson Cc: arch@freebsd.org Subject: Re: removal of kvtop() on i386 In-reply-to: Your message of "Mon, 17 Jul 2000 08:41:00 MDT." <200007171441.IAA22202@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jul 2000 11:47:23 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Has anybody though about how to change this for > architectures like Sparc where the whole idea of handing > a physical address to the drivers on a bus doesn't apply, and > where a unmapping/cache flushing operation must be done > at io completion. Yes. The busspace/busdma abstractions hide all of this by giving you a set of functions which translate from "virtual space" to "bus space" where the latter reflects a device on a specific buss' perception of physical memory. This abstraction includes map/unmap as well as pre and post sync hooks, functions to allocate bus-visible memory, scatter/gather list generation, etc. About the only thing currently missing is explicit support for mbuf chains, and the NetBSD folks have had code to handle that for quite some time now. -- ... 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] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 12: 1:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id DBD7137BC1F; Mon, 17 Jul 2000 12:01:25 -0700 (PDT) (envelope-from julian@elischer.org) Received: from timbuktu-01.budapest.interware.hu ([195.70.51.193] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13EG8Z-0006mg-00; Mon, 17 Jul 2000 21:01:08 +0200 Message-ID: <397357DE.2781E494@elischer.org> Date: Mon, 17 Jul 2000 12:00:46 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Warner Losh Cc: Brian Fundakowski Feldman , freebsd-arch@FreeBSD.org Subject: Re: SysctlFS References: <200007160740.BAA51827@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > > But this sort of thing is potentially worse. If you can follow the > symlink out of jail, can you use it to get to other files? > > The only way that device nodes exist in the jail now is if the jailors > create them for the Jail. Ditto with mount points. Ditto with this. > > I'm sure that any sort of automatic adding of device nodes to a > jail'd process' space is wrong by default. All things that aren't > explicitly permitted are forbidden. > : > Why bother with a symlink? Why not have a reference to the real > : > dev_t? > : > : The dev_t of what, exactly? > > The device that the jailed process can access. Right now we put the > dev_t in the hierarchy of the jailed process, which is the userland > dev_t. With a devfs implementation, you could put the kerneland dev_t > into the filesystem generally. If you do that, then you'll need to do > that in jail as well. If you don't, mknod is suffient for jailed > processes, plus maybe with a major number lookup routine (kernel, tell > me what the major number for wd). See my other email onn this topic.. I don;t propose Symlinks.. that would eba security whole. I propose a SYMLINK_LIKE MECHANISM to replace major numbers in normal cdev nodes created within the filesystem, that reflect into the device namespace. > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 12: 1:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id D369D37BB77; Mon, 17 Jul 2000 12:01:30 -0700 (PDT) (envelope-from julian@elischer.org) Received: from timbuktu-01.budapest.interware.hu ([195.70.51.193] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13EG8j-0006nR-00; Mon, 17 Jul 2000 21:01:17 +0200 Message-ID: <397357E7.794BDF32@elischer.org> Date: Mon, 17 Jul 2000 12:00:55 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Warner Losh Cc: Kelly Yancey , Robert Watson , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: SysctlFS References: <200007160752.BAA52125@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message Kelly Yancey writes: > : I didn't mean when you mounted the jail, but rather when you mounted the > : filesystem in question (i.e. /dev or /proc). The mount flag would be used to > : indicate that is mount is to transcend jails. In other words, when building a > : list of the current mount points inside a jail, mount with this flag would > : always be included. It is arguably a hack, but I don't see why it wouldn't > : work. > > You certainly don't want to do that for /dev in jails. The whole > point of jails is that you can give them access to a small subset of > devices that are "safe". > My suggestion is not that you allow symlinks to jump out of a jail for devices, but rather, the major and minor numbers presently used to connect the inode to the device be replaced by an ascii string (stored in the cdev inode in the same way a symlink is currently stored in the block pointer space) that connects to the appropriatly named node in. 1/ a devfs tree, or 2/ the phk device vnode stuff, either of which can map an name to a driver/minor# combination. It's not a symlink, it's just a 60 byte major number. You use the device canonical name as a limking mechanism in thesame way we currently use the major number. You still have a devfs on /devfs, because you still want new devices to show up somewhere, but you have the auxhiliary access mechanism of making individual nodes in the filesystem and having them access the arbitrarily named devices. (then major numbers can go away completely and all devices can be dynamic) -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 12: 1:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 1C1A337BC1F; Mon, 17 Jul 2000 12:01:49 -0700 (PDT) (envelope-from julian@elischer.org) Received: from timbuktu-01.budapest.interware.hu ([195.70.51.193] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13EG8T-0006m9-00; Mon, 17 Jul 2000 21:01:02 +0200 Message-ID: <397357D7.167EB0E7@elischer.org> Date: Mon, 17 Jul 2000 12:00:39 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Robert Watson , Warner Losh , Kelly Yancey , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) References: <2365.963743367@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning has some well meaning ideas but I disagree with him on several topics.. 1/ jail/chroot cannot be ignored.. see my email on cdevs using a "60 byte" major number for a solution to this.. 2/ The root mount problem can be easily solved if you allow the kernel to open devices by name from the devfs namespace without first mounting the device in user space. I did this on the code He and sos deleted and it worked just fine. Poul-Henning Kamp wrote: > > OK, now I finally have time to sit down and write an email with the > complete picture about devfs. > > For a moment, disregard jails and rootmounts and let us just look at > cloning. they cannot be ignored as thay represent a significant usage model. many programs expect a working /dev/tty for example. > > Cloning means that a device driver doesn't have to call make_dev() > on all potential instances up front. > > This makes most difference for pseudo-devices, tun, ppp, slip, pty, > md bpf and so on, but other "actual" drivers like fd could use it > as well to avoid calling make_dev() for every conceiveable format > of floppydisk. > > Implementing cloning without devfs would be a gross hack: we would > have to magically notice that /dev was searched and nothing found, > and I think we might just as well forget everything about that idea. > > Implementing cloning with devfs is simple: I agree with what he says.. > > Device-drivers can call devfs during their initialization and > register a "clone()" function with devfs. (They obviously have > to deregister it again at dettach time). > > When devfs::VOP_LOOKUP() fails to find the name it is being told > to look for, it will call all registered clone() routines > successively with the sought after name as argument. > > Each driver clone routine examine the name, and if it can > instantiate a device of that name, it does so with make_dev() > and return EEXISTS. If it cannot it returns 0. If it > can determine for good that the name should not exist at this > time it returns ENOENT; > > If a clone routine return EEXISTS, devfs::VOP_LOOKUP() > immediately retries the lookup, and returns the result. > > If a clone routine returns ENOENT, devfs::VOP_LOOKUP() fails > with ENOENT; > > When a clone routine returns 0, devfs::VOP_LOOKUP() calls the > next clone routine in turn. > > If when all clone routines have been called none of them have > instantiated, devfs::VOP_LOOKUP() returns ENOENT; > > The dev_t's created this way at not special in any way, all normal > rules and rights apply. The only thing special about this is > the "lazy creation" of dev_t's. > > Next, let us look at the rootfs: > > Today when we boot a FreeBSD system, various magic code finds and > mounts a root filesystem from which we execute /sbin/init (and the > rest becomes history). > > A part of this ha^h^hmagic, is to take a device name, and come up > with a vnode from which we can mount it, despite the fact that we > have no filesystems mounted which can instantiate that vnode. > Rather hackish, all in all. devfs as it is now has routines to do this.. > > Other magic code will do similar gyrations to mount a NFS root > filesystem. Since you don't need a device to mount an NFS filesystem this is not directly relevent. > > This obviously is a chicken and egg issue, and there are probably > no solution which is universally acceptable. My personal preference > is somewhat in the direction of what AIX have done, but with some > slight modifications: > > Kernel initializes, probes devices and all that. > > Kernel mounts a devfs instance on / > > Kernel mounts a preloaded (or compiled in) md(4) instance > in /bootfs > > Kernel executes /bootfs/init > > /bootfs/init examines the environment to find the kind of desired > root filesystem. > > nfs: /bootfs/init will initialize a network interface (using > DHCP for instance) and union mount (not unionfs!) > the root filesystem on / > > ufs: /bootfs/init will execute "/bootfs/fsck -p $device", and > afterwards unionmount (still not unionfs!) the > device on / > > others: Whatever is needed. > > After mounting the desired root filesystem, /bootfs/init does an > execl("/sbin/init", "/sbin/init", 0); so that the "real" init(8) > is started as pid==1 as required. > > I see many advantages to this scheme, the main thing is that a lot > of h0h0magic code moves from the kernel into userland. > > The /bootfs md(4) instance can be kept around, it will be very small, > but it can also be unmounted and if our VM system is taught how to, > the RAM can be recycled. > > This scheme will also take all the pain out of things like raid-5 > rootfs: No more kernel h0h0magic code needed, just add the vinum > program to /bootfs and DTRT. this seems overly complicated to me. > > /bootfs/init could conveniently be a shell script btw. > > Finally, jails: > > The only reason there could ever be to mount a devfs in a jail > partition is to get access to the cloning facility, mainly for > ptys. For the /dev/null, /dev/zero etc cases, a good oldfashioned > mknod(8) will do just fine. Remember: the main reason for devfs > is to cater for dynamic devices, the main thing we don't want to > see pop up in jails is dynamic devices. If we us a "SYMLINK-LIKE" major number replacement, that links an on-disk device inode to the current devfs canonical namespace, then no extra devfs's need to be mounted, and the cloning facilities in devfs will be available to any inode that links to a cloning device. This implies that the BASE SYSTEM is taught how to handle "string" type major numbers and look them up in the devfs by name, or search through the dev_t nodes in a non_devfs kernel to find the appropriate driver and cookie (minor number). By extension /dev could remain an on-disk item and have all links to /devfs which would solve some of the screams for persistance because the permissions and ownerships would be taken from teh cdev nodes on the disk. If you went to /devfs you would get the default version of permissions and such Basically I'm suggesting SUPLEMENTING devfs with an alternate method of reaching the devices, which uses the devfs canonical namespace as a linking mechanism. > > So the devfs vs jail issue almost entirely boils down to "what do > we do about ptys in jails" and considering that it actually works > now in "the good old way", I frankly can't see much reason to > not just continue that way. Few jails are pty intensive anyway. > > Summary: > > 1. Forget about jails in the context of devfs, we don't need it. > > 2. We can argue if we should unionmount the "real root" over a > devfs, or if we should mount devfs on /dev. Both arguments > have some amount of merit: The former is cleaner, the latter > is more like it used to be. > > 3. Cloning while not strictly a must, is highly desireable. > > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 12:55:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 2F16B37BAC4 for ; Mon, 17 Jul 2000 12:55:38 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id VAA37368; Mon, 17 Jul 2000 21:55:29 +0200 (CEST) (envelope-from des@flood.ping.uio.no) To: Michael Lucas Cc: alex@big.endian.de (Alexander Langer), freebsd-arch@FreeBSD.ORG Subject: Re: Bikesheds References: <200007171805.OAA05517@blackhelicopters.org> From: Dag-Erling Smorgrav Date: 17 Jul 2000 21:55:29 +0200 In-Reply-To: Michael Lucas's message of "Mon, 17 Jul 2000 14:05:16 -0400 (EDT)" Message-ID: Lines: 21 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Lucas writes: > It's like construction work. Very few people can build a skyscraper, > but anyone can build a bike shed. > > When someone mentions "painting the bikeshed" it means "we've argued > about this long enough, most of the solutions are just fine, will you > please just implement one and SHUT UP?" Bzzt, wrong, but thanks for playing. A bikeshed discussion is a discussion about a bikeshed which everyone agrees would be nice to have in the back yard, but will fight until death to stop it from being built because, as they repeatedly and loudly point out, the suggested paint scheme is just *wrong*. I seem to recall this actually refers to a true story about a real bikeshed; ask phk for details. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 13: 5:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 15ED137BBFA for ; Mon, 17 Jul 2000 13:05:49 -0700 (PDT) (envelope-from wkb@freebie.demon.nl) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 13EH98-0006S5-00; Mon, 17 Jul 2000 20:05:47 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.9.3/8.9.3) id WAA77605; Mon, 17 Jul 2000 22:05:46 +0200 (CEST) (envelope-from wkb) Date: Mon, 17 Jul 2000 22:05:46 +0200 From: Wilko Bulte To: Dag-Erling Smorgrav Cc: Michael Lucas , Alexander Langer , freebsd-arch@freebsd.org Subject: Re: Bikesheds Message-ID: <20000717220546.A77536@freebie.demon.nl> Reply-To: wilko@freebsd.org References: <200007171805.OAA05517@blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from des@flood.ping.uio.no on Mon, Jul 17, 2000 at 09:55:29PM +0200 X-OS: FreeBSD 4.0-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 17, 2000 at 09:55:29PM +0200, Dag-Erling Smorgrav wrote: > Michael Lucas writes: > > It's like construction work. Very few people can build a skyscraper, > > but anyone can build a bike shed. > > > > When someone mentions "painting the bikeshed" it means "we've argued > > about this long enough, most of the solutions are just fine, will you > > please just implement one and SHUT UP?" > > Bzzt, wrong, but thanks for playing. > > A bikeshed discussion is a discussion about a bikeshed which everyone > agrees would be nice to have in the back yard, but will fight until > death to stop it from being built because, as they repeatedly and > loudly point out, the suggested paint scheme is just *wrong*. > > I seem to recall this actually refers to a true story about a real > bikeshed; ask phk for details. Most bikesheds around here end nowhere because of government regulations standing in your way building one. Wrong color ("does not fit within the local surroundings") is just one reason. :) -- Wilko Bulte http://www.freebsd.org wilko@freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 13:36:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.osd.bsdi.com (zippy.osd.bsdi.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id E6C3437BC13 for ; Mon, 17 Jul 2000 13:36:24 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id NAA07039; Mon, 17 Jul 2000 13:36:31 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: Dag-Erling Smorgrav Cc: Michael Lucas , alex@big.endian.de (Alexander Langer), freebsd-arch@FreeBSD.ORG Subject: Re: Bikesheds In-reply-to: Your message of "17 Jul 2000 21:55:29 +0200." Date: Mon, 17 Jul 2000 13:36:31 -0700 Message-ID: <7036.963866191@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Bzzt, wrong, but thanks for playing. > > A bikeshed discussion is a discussion about a bikeshed which everyone > agrees would be nice to have in the back yard, but will fight until > death to stop it from being built because, as they repeatedly and > loudly point out, the suggested paint scheme is just *wrong*. Actually, as someone who remembers phk's original discussion (and the citation of some Danish aphorism from which it springs), this is wrong too. :-) It has to do with getting planning permits and building the damn thing at all. You can generally get permission to build a sky-scraper since that just involves greasing a few politicians and dealing with the people downtown, but try and put a bike shed on the corner in your neighborhood... - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 13:51:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 9CC8437BCD9 for ; Mon, 17 Jul 2000 13:51:27 -0700 (PDT) (envelope-from brdavis@orion.ac.hmc.edu) Received: (from brdavis@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) id NAA25932; Mon, 17 Jul 2000 13:50:55 -0700 (PDT) Date: Mon, 17 Jul 2000 13:50:55 -0700 From: Brooks Davis To: "Jordan K. Hubbard" Cc: Dag-Erling Smorgrav , Michael Lucas , Alexander Langer , freebsd-arch@FreeBSD.ORG Subject: Re: Bikesheds Message-ID: <20000717135055.B23145@orion.ac.hmc.edu> References: <7036.963866191@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <7036.963866191@localhost>; from jkh@zippy.osd.bsdi.com on Mon, Jul 17, 2000 at 01:36:31PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 17, 2000 at 01:36:31PM -0700, Jordan K. Hubbard wrote: > > Bzzt, wrong, but thanks for playing. > > Actually, as someone who remembers phk's original discussion (and the > citation of some Danish aphorism from which it springs), this is wrong > too. :-) Nobody seems to be remember it right so I dug it up in the archives. Here's the URL to the archives (didn't these used to be shorter?): http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers Here's the relavent part of PHK's message for the lazy: > "What is it about this bike shed ?" Some of you have asked me. > > It's a long story, or rather it's an old story, but it is quite > short actually. C. Northcote Parkinson wrote a book in the early > 1960'ies, called "Parkinson's Law", which contains a lot of insight > into the dynamics of management. > > [snip a bit of commentary on the book] > > Parkinson shows how you can go in to the board of directors and > get approval for building a multi-million or even billion dollar > atomic power plant, but if you want to build a bike shed you will > be tangled up in endless discussions. > > Parkinson explains that this is because an atomic plant is so vast, > so expensive and so complicated that people cannot grasp it, and > rather than try, they fall back on the assumption that somebody > else checked all the details before it got this far. Richard P. > Feynmann gives a couple of interesting, and very much to the point, > examples relating to Los Alamos in his books. > > A bike shed on the other hand. Anyone can build one of those over > a weekend, and still have time to watch the game on TV. So no > matter how well prepared, no matter how reasonable you are with > your proposal, somebody will seize the chance to show that he is > doing his job, that he is paying attention, that he is *here*. > > In Denmark we call it "setting your fingerprint". It is about > personal pride and prestige, it is about being able to point > somewhere and say "There! *I* did that." It is a strong trait in > politicians, but present in most people given the chance. Just > think about footsteps in wet cement. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 14: 0:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 7230737BBD0 for ; Mon, 17 Jul 2000 14:00:44 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA92875; Mon, 17 Jul 2000 15:00:15 -0600 (MDT) (envelope-from ken) Date: Mon, 17 Jul 2000 15:00:15 -0600 From: "Kenneth D. Merry" To: Neil Blakey-Milner Cc: arch@FreeBSD.ORG Subject: Re: Conditionally removing cosmetic messages for small kernels (PICOBSD). Message-ID: <20000717150015.A92780@panzer.kdm.org> References: <20000717152514.A2056@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000717152514.A2056@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Mon, Jul 17, 2000 at 03:25:14PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 17, 2000 at 15:25:14 +0200, Neil Blakey-Milner wrote: > Hi, > > While building a PicoBSD disk for work purposes, I noticed that > pcisupport.c was the largest object file sitting there, at 43k. > > By removing (#ifndef PICOBSD, better names accepted) the cosmetic probe > messages, I managed to reduce that to 23k easily enough, buying me a few > more executables (and NTFS support, which was why I was building the > disk). I would call it PCI_NO_STRINGS or maybe PCI_NO_DESCRIPTIONS, so that it can be easily used with something other than PicoBSD, and so it is a little more self-documenting. > If I were to do/start the work on the rest of the system, would this be > acceptable? Initial patch attached. (There seems to be "quirk" fixes > mixed in with the cosmetic stuff, so the patches aren't as clean as they > could be.) I think you'll find that most other areas of the system with large numbers of strings have already been taken care of. The only area other than the PCI code that I can think of with lots of text is CAM, and that has been #ifdef'ed since the beginning. For both the PCI code and the CAM code, though, I think the strings should be compiled out only when necessary. (like for PicoBSD) In most cases, the win from having the strings is far greater than the size cost. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 14:13:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id CC66137BDFA; Mon, 17 Jul 2000 14:11:08 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA04575; Mon, 17 Jul 2000 23:10:57 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: alex@big.endian.de (Alexander Langer) Cc: James Howard , Ben Smithurst , Brian Somers , freebsd-hackers@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: /etc/security -> /etc/periodic/security ? In-reply-to: Your message of "Mon, 17 Jul 2000 18:39:18 +0200." <20000717183918.A26484@cichlids.cichlids.com> Date: Mon, 17 Jul 2000 23:10:57 +0200 Message-ID: <4573.963868257@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000717183918.A26484@cichlids.cichlids.com>, Alexander Langer writ es: >Thus spake James Howard (howardjp@glue.umd.edu): > >> fairings? Why does it matter what color the bikeshed is? What does > >What is this thing with the bikesheds??? > >It appears on every place I am, on IRC, now here. > >As a non-native English-speaker, I'd like to know what's up with the >poor bikesheds. The poor ones :-( It's a reference to a particular apt description of how committees work and don't work from the excellent book: Parkinson's Law C. Northcote Parkinson Buccaneer Books ISBN 1-56849-015-1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 14:20:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 9177337BB60; Mon, 17 Jul 2000 14:20:38 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA04774; Mon, 17 Jul 2000 23:20:30 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Robert Watson , Warner Losh , Kelly Yancey , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) In-reply-to: Your message of "Mon, 17 Jul 2000 12:00:39 PDT." <397357D7.167EB0E7@elischer.org> Date: Mon, 17 Jul 2000 23:20:30 +0200 Message-ID: <4772.963868830@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <397357D7.167EB0E7@elischer.org>, Julian Elischer writes: >Poul-Henning has some well meaning ideas but I disagree >with him on several topics.. > >1/ jail/chroot cannot be ignored.. >see my email on cdevs using a "60 byte" major number >for a solution to this.. I'm not saying it can be ignored. I'm saying that it is not worth complicating the issue with big time. Your "symlink device node" proposal still doesn't solve the cloning problem, so it is only 1/2 a solution to what in practice is a non-problem. >2/ The root mount problem can be easily solved if you allow >the kernel to open devices by name from the devfs namespace >without first mounting the device in user space. >I did this on the code He and sos deleted and it worked just fine. No, your code still built a vnode with no backing filesystem (it had no v_mount for instance) and that still forced a lot of special case code in generic vfs functions). >> For a moment, disregard jails and rootmounts and let us just look at >> cloning. > >they cannot be ignored as thay represent a significant usage model. >many programs expect a working /dev/tty for example. But /dev/tty can just be mknod(8)'d in the jail, and it will just work as it should. >> Next, let us look at the rootfs: >> >> Today when we boot a FreeBSD system, various magic code finds and >> mounts a root filesystem from which we execute /sbin/init (and the >> rest becomes history). >> >> A part of this ha^h^hmagic, is to take a device name, and come up >> with a vnode from which we can mount it, despite the fact that we >> have no filesystems mounted which can instantiate that vnode. >> Rather hackish, all in all. > >devfs as it is now has routines to do this.. No it hasn't, the vnode still has to be magically handled because it doesn't have a mountpoint. >> Other magic code will do similar gyrations to mount a NFS root >> filesystem. > >Since you don't need a device to mount an NFS filesystem this >is not directly relevent. see later. (always read the entire message before replying :-) >> Finally, jails: >> >> The only reason there could ever be to mount a devfs in a jail >> partition is to get access to the cloning facility, mainly for >> ptys. For the /dev/null, /dev/zero etc cases, a good oldfashioned >> mknod(8) will do just fine. Remember: the main reason for devfs >> is to cater for dynamic devices, the main thing we don't want to >> see pop up in jails is dynamic devices. > >If we us a "SYMLINK-LIKE" major number replacement, >that links an on-disk device inode to the current devfs >canonical namespace, then no extra devfs's need to be mounted, >and the cloning facilities in devfs will be available >to any inode that links to a cloning device. Your "SYMLINK-LINK" proposal offers nothing that we don't already have with major/minor identification, which for all intents and purposes we will have to retain compatibility with for quite some time anyway. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 17: 7:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id E251A37B781 for ; Mon, 17 Jul 2000 17:07:14 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.15 #1) id 13EKuX-000KVD-00; Tue, 18 Jul 2000 07:06:57 +0700 Date: Tue, 18 Jul 2000 07:06:57 +0700 (ALMST) From: Boris Popov To: Neil Blakey-Milner Cc: arch@FreeBSD.org Subject: Re: Conditionally removing cosmetic messages for small kernels (PICOBSD). In-Reply-To: <20000717152514.A2056@mithrandr.moria.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 17 Jul 2000, Neil Blakey-Milner wrote: > While building a PicoBSD disk for work purposes, I noticed that > pcisupport.c was the largest object file sitting there, at 43k. > > By removing (#ifndef PICOBSD, better names accepted) the cosmetic probe > messages, I managed to reduce that to 23k easily enough, buying me a few > more executables (and NTFS support, which was why I was building the > disk). This is also related to the identcpu.c and i686_mem.c files. While building a very small kernel (nanobsd :) for i486 based system I've noted that i686_mem.c compiled always regardless of 'cpu' keyword in the config file (why one need it on 486...). Similarly, identcpu.c code can reduced by excluding probes and corresponding messages for Pentiums if one needs only i486 support. A more general question: should we allow more options to exclude optional and obsolete parts of the kernel ? For example, I've ripped out aout, aio and jail related code without any effect on functionality for my particular system. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 18:18:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id ED03437B78E for ; Mon, 17 Jul 2000 18:18:07 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6I1HtL26327; Mon, 17 Jul 2000 18:17:55 -0700 (PDT) Date: Mon, 17 Jul 2000 18:17:55 -0700 From: Alfred Perlstein To: Boris Popov Cc: Neil Blakey-Milner , arch@FreeBSD.ORG Subject: Re: Conditionally removing cosmetic messages for small kernels (PICOBSD). Message-ID: <20000717181754.A13979@fw.wintelcom.net> References: <20000717152514.A2056@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from bp@butya.kz on Tue, Jul 18, 2000 at 07:06:57AM +0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Boris Popov [000717 17:07] wrote: > > A more general question: should we allow more options to exclude > optional and obsolete parts of the kernel ? For example, I've ripped out > aout, aio and jail related code without any effect on functionality for my > particular system. I'm sure our friends in the embedded systems world would say yes. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 22:10: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 9F1FB37BB47 for ; Mon, 17 Jul 2000 22:09:51 -0700 (PDT) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 7C15ED8E for ; Mon, 17 Jul 2000 22:09:51 -0700 (PDT) Received: from cup.hp.com (p1000180.nsr.hp.com [15.109.0.180]) by adlmail.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id WAA29044 for ; Mon, 17 Jul 2000 22:09:43 -0700 (PDT) Message-ID: <3973E698.B8D53F1F@cup.hp.com> Date: Mon, 17 Jul 2000 22:09:44 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.org Subject: Multiple kernels / module search path Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm about to work on the buildkernel and installkernel targets in makefile.inc1. Currently we can build multiple kernels (with their modules) and install just one kernel (with its modules). PR 17698 has a patch to allow multiple kernels to be installed. Question 1: Do we want the ability to install multiple kernels? Assume for a moment that we don't want to install multiple kernels; we still need to improve the support for having multiple kernels in / if we continue to rename the existing kernel (and modules directory) when we install a new one. The problem is that the old kernel (ie kernel.old) still has /:/boot:/modules as the module search path while the modules directory that corresponds to this kernel is modules.old. Therefore booting any kernel other than 'kernel' is potentially dangerous. If we do want the support to install multiple kernels with the installkernel target, we face the same problem. Say that we install the first kernel as "kernel" with modules directory "/modules". The module search path is correct in this case. Other kernels are installed as, say, kernel.NAME. These kernels should have their modules directory be set to "/modules.NAME". But we also have to make sure that their module search path is adjusted properly. Question 2: Is the above naming scheme acceptable? Question 3: Should we change the order in which modules are searched to /modules{.NAME}:/boot:/, where {.NAME} denotes the optional name suffix. Question 4: Do we want /modules in the search for kernels with a non-zero name so that the search path will be /modules.NAME:/modules:/boot:/ It's a bit cryptic at places, but I hope the general idea has been communicated sufficiently. Your feedback is appreciated, BTW: My personal preference is "yes, yes, yes, no" :-) -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 17 23:14:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 8FAA937B6BF for ; Mon, 17 Jul 2000 23:14:17 -0700 (PDT) (envelope-from brdavis@orion.ac.hmc.edu) Received: (from brdavis@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) id XAA09376; Mon, 17 Jul 2000 23:03:51 -0700 (PDT) Date: Mon, 17 Jul 2000 23:03:51 -0700 From: Brooks Davis To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path Message-ID: <20000717230351.C6353@orion.ac.hmc.edu> References: <3973E698.B8D53F1F@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <3973E698.B8D53F1F@cup.hp.com>; from marcel@cup.hp.com on Mon, Jul 17, 2000 at 10:09:44PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 17, 2000 at 10:09:44PM -0700, Marcel Moolenaar wrote: > Question 4: Do we want /modules in the search for kernels with a > non-zero name so that the search path will be > /modules.NAME:/modules:/boot:/ I agree with you except here (and you may be able to find a solution here.) My problem with not doing this is that ports and third party software that creates modules (vmware, etc) needs a place to put them, and currently that's modules. While you could put them in /boot, that seems ugly at best. Otherwise, I like ideas very much. I've been wanting to build and install my custom kernel and GENERIC in one fell swoop since {build|install}kernel was added. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 1: 0:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5]) by hub.freebsd.org (Postfix) with ESMTP id 142B237B8D5 for ; Tue, 18 Jul 2000 01:00:10 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by mimer.webgiro.com (Postfix, from userid 66) id 9E2802DC0B; Tue, 18 Jul 2000 10:05:28 +0200 (CEST) Received: by mx.webgiro.com (Postfix, from userid 1001) id 2656E7817; Tue, 18 Jul 2000 09:55:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.webgiro.com (Postfix) with ESMTP id 2163010E17; Tue, 18 Jul 2000 09:55:59 +0200 (CEST) Date: Tue, 18 Jul 2000 09:55:59 +0200 (CEST) From: Andrzej Bialecki To: Alfred Perlstein Cc: Boris Popov , Neil Blakey-Milner , arch@FreeBSD.ORG Subject: Re: Conditionally removing cosmetic messages for small kernels (PICOBSD). In-Reply-To: <20000717181754.A13979@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 17 Jul 2000, Alfred Perlstein wrote: > * Boris Popov [000717 17:07] wrote: > > > > A more general question: should we allow more options to exclude > > optional and obsolete parts of the kernel ? For example, I've ripped out > > aout, aio and jail related code without any effect on functionality for my > > particular system. > > I'm sure our friends in the embedded systems world would say yes. :) For well-known set of applications you may want also to remove COMPAT_43. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 3:31: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5DFC337BD5B; Tue, 18 Jul 2000 03:30:59 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id UAA17525; Tue, 18 Jul 2000 20:30:12 +1000 Date: Tue, 18 Jul 2000 20:30:05 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Alfred Perlstein Cc: Alexander Langer , Sheldon Hearn , Assar Westerlund , Brian Fundakowski Feldman , arch@FreeBSD.ORG Subject: Re: kernel printf %i? In-Reply-To: <20000717024029.A24382@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 17 Jul 2000, Alfred Perlstein wrote: > * Alexander Langer [000717 01:56] wrote: > > Thus spake Alfred Perlstein (bright@wintelcom.net): > > > > > > What ANSI standard covers _kernel_ printf()? > > > POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA POLA > > > > POLA is a good argument. I was VERY surprised about having to use %d. > > I'm a '%d man' but I had just been reading some C books and all the > code was using %i, I was suprised when it didn't work. You've been reading the wrong books :-). The C99 draft (version n869.txt) has 19 lines in examples that use plain %d, and 0 lines in examples that use plain %i. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 3:33:24 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout2.silyn-tek.de (mout2.silyn-tek.de [194.25.165.70]) by hub.freebsd.org (Postfix) with ESMTP id ECE4C37BD5B; Tue, 18 Jul 2000 03:33:20 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.33] (helo=mx1.silyn-tek.de) by mout2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EUgg-0003M9-00; Tue, 18 Jul 2000 12:33:18 +0200 Received: from p3e9c114a.dip0.t-ipconnect.de ([62.156.17.74] helo=neutron.cichlids.com) by mx1.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EUgd-0002iC-00; Tue, 18 Jul 2000 12:33:15 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id A45D9AB91; Tue, 18 Jul 2000 12:34:47 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id DF5D714AA3; Tue, 18 Jul 2000 12:33:16 +0200 (CEST) Date: Tue, 18 Jul 2000 12:33:16 +0200 From: Alexander Langer To: Bruce Evans Cc: Alfred Perlstein , Sheldon Hearn , Assar Westerlund , Brian Fundakowski Feldman , arch@FreeBSD.ORG Subject: Re: kernel printf %i? Message-ID: <20000718123316.A28133@cichlids.cichlids.com> References: <20000717024029.A24382@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from bde@zeta.org.au on Tue, Jul 18, 2000 at 08:30:05PM +1000 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Bruce Evans (bde@zeta.org.au): > You've been reading the wrong books :-). The C99 draft (version n869.txt) > has 19 lines in examples that use plain %d, and 0 lines in examples that > use plain %i. Well, I read K&R's 2nd book :) (The only C book I read). Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 6: 7:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 8BFE637B9CC for ; Tue, 18 Jul 2000 06:07:13 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id OAA43896; Tue, 18 Jul 2000 14:05:10 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id NAA26364; Tue, 18 Jul 2000 13:36:28 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <7036.963866191@localhost> References: Your message of "17 Jul 2000 21:55:29 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jul 2000 13:36:28 +0100 To: "Jordan K. Hubbard" From: Bob Bishop Subject: Re: Bikesheds Cc: Dag-Erling Smorgrav , Michael Lucas , alex@big.endian.de (Alexander Langer), freebsd-arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, >> A bikeshed discussion is ... A metabikeshed discussion, on the other hand, is one where the protagonists try to recall in minute detail both the meaning and the etymology of some arcane piece of terminology. Such terms commonly involve the pathological properties of some metaphorical object (ISTR something about fairings in the past), hence the discussion has a tendency to stray into aetiology. Metabikeshed discussions share with the bikeshed variety the property that, while entertaining, they tend to absorb rather a lot of list bandwidth for reasons already noted. Glossary anyone? -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 6:12:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 8461537BDA2 for ; Tue, 18 Jul 2000 06:12:33 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.15 #1) id 13EXAX-000CvM-00; Tue, 18 Jul 2000 15:12:17 +0200 From: Sheldon Hearn To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path In-reply-to: Your message of "Mon, 17 Jul 2000 22:09:44 MST." <3973E698.B8D53F1F@cup.hp.com> Date: Tue, 18 Jul 2000 15:12:17 +0200 Message-ID: <49681.963925937@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 17 Jul 2000 22:09:44 MST, Marcel Moolenaar wrote: > Question 3: Should we change the order in which modules are searched to > /modules{.NAME}:/boot:/, where {.NAME} denotes the optional name suffix. I really don't think that this is the way to go. A module should be a module should be a module. That's certainly where we're headed, right? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 9:24:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 1506437BDB8 for ; Tue, 18 Jul 2000 09:24:40 -0700 (PDT) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 527E710DF; Tue, 18 Jul 2000 09:20:43 -0700 (PDT) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA16655; Tue, 18 Jul 2000 09:20:39 -0700 (PDT) Message-ID: <397483D7.DFEC9BBC@cup.hp.com> Date: Tue, 18 Jul 2000 09:20:39 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis Cc: arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path References: <3973E698.B8D53F1F@cup.hp.com> <20000717230351.C6353@orion.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brooks Davis wrote: > > On Mon, Jul 17, 2000 at 10:09:44PM -0700, Marcel Moolenaar wrote: > > Question 4: Do we want /modules in the search for kernels with a > > non-zero name so that the search path will be > > /modules.NAME:/modules:/boot:/ > > I agree with you except here (and you may be able to find a solution > here.) My problem with not doing this is that ports and third party > software that creates modules (vmware, etc) needs a place to put them, > and currently that's modules. While you could put them in /boot, that > seems ugly at best. Otherwise, I like ideas very much. I've been > wanting to build and install my custom kernel and GENERIC in one fell > swoop since {build|install}kernel was added. The problem is with versioning. If I add 3rd party module foo.ko to modules, while it actually is a module for kernel 'kernel.bar' *and* kernel and kernel.bar are sufficiently incompatible, then kernel won't boot (for example) if the module is loaded at boot time. Or, if kernel.bar is booted and I want to load foo.ko, I might pick up the version from /modules if I don't happen to have a foo.ko in /modules.bar, which may be sufficiently incompatible and cause a kernel panic. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 9:32:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 7747037BEEA for ; Tue, 18 Jul 2000 09:32:29 -0700 (PDT) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id 13FEB18C0; Tue, 18 Jul 2000 09:32:28 -0700 (PDT) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id JAA17075; Tue, 18 Jul 2000 09:32:26 -0700 (PDT) Message-ID: <3974869B.22E7924@cup.hp.com> Date: Tue, 18 Jul 2000 09:32:27 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path References: <49681.963925937@axl.ops.uunet.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Mon, 17 Jul 2000 22:09:44 MST, Marcel Moolenaar wrote: > > > Question 3: Should we change the order in which modules are searched to > > /modules{.NAME}:/boot:/, where {.NAME} denotes the optional name suffix. > > I really don't think that this is the way to go. A module should be a > module should be a module. That's certainly where we're headed, right? Building the modules as part of the kernel seems like a step away from it, because if modules are modules are modules, we could build them as part of world as we used to do and avoid building and rebuilding modules with every kernel we're building. But building modules as part of the world resulted in kernel and modules to be out of sync. We all know what that means :-) We currently don't have the interfaces to make that happen (modules being modules that is). This implies that different installed kernels can not always share the same /modules directory. This is especially true during an upgrade, when the new kernel will be version V.x and the old kernel will be version (V-1).y. If we don't have a seperate /modules directory for the old kernel, we still have the "out-of-sync" problem. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 9:54:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id B2C1037B637 for ; Tue, 18 Jul 2000 09:54:13 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id JAA28211 for ; Tue, 18 Jul 2000 09:54:12 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA12222; Tue, 18 Jul 2000 09:54:12 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 18 Jul 2000 09:54:12 -0700 (PDT) Message-Id: <200007181654.JAA12222@vashon.polstra.com> To: arch@freebsd.org Subject: Re: final call: truncate into the base system or not? In-Reply-To: <20000716225543.A7308@cichlids.cichlids.com> References: <20000716225543.A7308@cichlids.cichlids.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000716225543.A7308@cichlids.cichlids.com>, Alexander Langer wrote: > > Since I can't recall any consensus whether importing or not, but only > about implementation details, I'd like to know, what the opinion of > _importing_ it into the base system is, _beside_ all implementation > details. Yes, please just do it. We don't need another 1 MB of discussion to bring in 9 KB of sources. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 14: 7:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id 1F49D37BBD5 for ; Tue, 18 Jul 2000 14:07:52 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA18973; Tue, 18 Jul 2000 14:13:59 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007182113.OAA18973@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path In-reply-to: Your message of "Tue, 18 Jul 2000 09:20:39 PDT." <397483D7.DFEC9BBC@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 14:13:59 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The problem is with versioning. If I add 3rd party module foo.ko to > modules, while it actually is a module for kernel 'kernel.bar' *and* > kernel and kernel.bar are sufficiently incompatible, then kernel won't > boot (for example) if the module is loaded at boot time. > > Or, if kernel.bar is booted and I want to load foo.ko, I might pick up > the version from /modules if I don't happen to have a foo.ko in > /modules.bar, which may be sufficiently incompatible and cause a kernel > panic. This has already been discussed to death, and consensus has been as follows: When a kernel is built and installed in the default fashion, a directory 'kernel' will be created. This directory will contain a file kernel.ko (the core kernel module) and any other modules configured to be built with the kernel (at this time, that's all of them). The actual name of this directory is of course subject to modification, and its final location (/, /boot, etc.) hasn't really been tied down. Entirely separately, there is a 'modules' directory, which is listed second on the module search path, and which contains modules not directly tied to the exact running instance of the kernel. ie. third-party modules, meta-information (splash screens, SCSI quirk tables, etc.). Note that with module versioning, you can't load an incompatible module, so that's not actually an issue. As long as there's a compatible version of a module somewhere on your search path, you'll be fine. -- ... 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] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 14:24:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (Postfix) with ESMTP id 722C437B80B; Tue, 18 Jul 2000 14:24:35 -0700 (PDT) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel1.hp.com (Postfix) with ESMTP id 380681102; Tue, 18 Jul 2000 14:24:34 -0700 (PDT) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA00422; Tue, 18 Jul 2000 14:24:33 -0700 (PDT) Message-ID: <3974CB11.388FE532@cup.hp.com> Date: Tue, 18 Jul 2000 14:24:33 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path References: <200007182113.OAA18973@mass.osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > The problem is with versioning. If I add 3rd party module foo.ko to > > modules, while it actually is a module for kernel 'kernel.bar' *and* > > kernel and kernel.bar are sufficiently incompatible, then kernel won't > > boot (for example) if the module is loaded at boot time. > > > > Or, if kernel.bar is booted and I want to load foo.ko, I might pick up > > the version from /modules if I don't happen to have a foo.ko in > > /modules.bar, which may be sufficiently incompatible and cause a kernel > > panic. > > This has already been discussed to death, and consensus has been as > follows: [snip] Ok, I'll make {build|install}kernel behave the same as the traditional way only and not add the ability to install multiple kernels. We can always revisit these targets when the improved infrastructure is in place. Thanks, -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 15:13:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 3E22C37B57D; Tue, 18 Jul 2000 15:13:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from luanda-23.budapest.interware.hu ([195.70.51.23] helo=jules.elischer.org) by mail.interware.hu with smtp (Exim 3.12 #1 (Debian)) id 13EfbY-0001Nh-00; Wed, 19 Jul 2000 00:12:45 +0200 Message-ID: <3974D642.59E2B600@elischer.org> Date: Tue, 18 Jul 2000 15:12:18 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Robert Watson , Warner Losh , Kelly Yancey , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) References: <4772.963868830@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > In message <397357D7.167EB0E7@elischer.org>, Julian Elischer writes: > >Poul-Henning has some well meaning ideas but I disagree > >with him on several topics.. > > > >1/ jail/chroot cannot be ignored.. > >see my email on cdevs using a "60 byte" major number > >for a solution to this.. > > I'm not saying it can be ignored. I'm saying that it is not > worth complicating the issue with big time. > > Your "symlink device node" proposal still doesn't solve the > cloning problem, so it is only 1/2 a solution to what in > practice is a non-problem. It allows the cloning devices to be represented all over the filesystems rather than limitted to the devfs, thus it allows them to be in chroot/jails without zillions of devfs mounts... I didn't say it was a magic bullet. I think it's a useful addition. > > >2/ The root mount problem can be easily solved if you allow > >the kernel to open devices by name from the devfs namespace > >without first mounting the device in user space. > >I did this on the code He and sos deleted and it worked just fine. > > No, your code still built a vnode with no backing filesystem (it > had no v_mount for instance) and that still forced a lot of special > case code in generic vfs functions). Actually I did have a v_mount that the root pointed to. > > >> For a moment, disregard jails and rootmounts and let us just look at > >> cloning. > > > >they cannot be ignored as thay represent a significant usage model. > >many programs expect a working /dev/tty for example. > > But /dev/tty can just be mknod(8)'d in the jail, and it will just > work as it should. That implies preallocating a major number. That's one of the things I'm trying to get away from. ASAP. (Also one of the thing kinus is trying to get away from with their devfs.) look up by NAME not by NUMBER.... > > >> Next, let us look at the rootfs: > >> > >> Today when we boot a FreeBSD system, various magic code finds and > >> mounts a root filesystem from which we execute /sbin/init (and the > >> rest becomes history). > >> > >> A part of this ha^h^hmagic, is to take a device name, and come up > >> with a vnode from which we can mount it, despite the fact that we > >> have no filesystems mounted which can instantiate that vnode. > >> Rather hackish, all in all. > > > >devfs as it is now has routines to do this.. > > No it hasn't, the vnode still has to be magically handled because > it doesn't have a mountpoint. It Is magically handled. it would still have to be magically handled in any scheme you've mentionned so far. Presently it has the "internal" mountpoint for the devfs backing layer before the root is mounted. this is a valid mountpoint from the point of view of all the code that looks at it. > > >> Other magic code will do similar gyrations to mount a NFS root > >> filesystem. > > > >Since you don't need a device to mount an NFS filesystem this > >is not directly relevent. > > see later. (always read the entire message before replying :-) I did > > >> Finally, jails: > >> > >> The only reason there could ever be to mount a devfs in a jail > >> partition is to get access to the cloning facility, mainly for > >> ptys. For the /dev/null, /dev/zero etc cases, a good oldfashioned > >> mknod(8) will do just fine. Remember: the main reason for devfs > >> is to cater for dynamic devices, the main thing we don't want to > >> see pop up in jails is dynamic devices. > > > >If we us a "SYMLINK-LIKE" major number replacement, > >that links an on-disk device inode to the current devfs > >canonical namespace, then no extra devfs's need to be mounted, > >and the cloning facilities in devfs will be available > >to any inode that links to a cloning device. > > Your "SYMLINK-LINK" proposal offers nothing that we don't already > have with major/minor identification, which for all intents > and purposes we will have to retain compatibility with for quite > some time anyway. We have pre-allocated major numbers. One of the MAIN aims of devfs was to make ALL devices dynamically loadable, which implies not limitting yourself to preallocated numbers. You can still get clashes on strings I know, but it's a different order of magnitude.. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ;_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 18:45:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id B1FDC37BBD1 for ; Tue, 18 Jul 2000 18:45:27 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id SAA16001; Tue, 18 Jul 2000 18:45:00 -0700 (PDT) (envelope-from obrien) Date: Tue, 18 Jul 2000 18:45:00 -0700 From: "David O'Brien" To: Alexander Langer , arch@freebsd.org Subject: Re: removal of kvtop() on i386 Message-ID: <20000718184500.E15761@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20000717155552.A19233@cichlids.cichlids.com> <200007171828.LAA10544@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007171828.LAA10544@mass.osd.bsdi.com>; from msmith@freebsd.org on Mon, Jul 17, 2000 at 11:28:03AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 17, 2000 at 11:28:03AM -0700, Mike Smith wrote: > > [reposting to -arch, where it is better] > > I recently wanted to port the if_ed driver to alpha. > > FreeBSD/alpha still misses kvtop(), so I implemented it. > > The 'ed' driver should be rewritten to use newbus/busspace, at which > point kvtop stops being an issue. I have to agree with Mike. Please do not dirty the Alpha code with obsoleted interfaces. The Alpha is a lot cleaner than our i386 code. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:13:17 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6954637BAF7; Tue, 18 Jul 2000 20:13:14 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA89188; Tue, 18 Jul 2000 21:13:13 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA76846; Tue, 18 Jul 2000 21:13:04 -0600 (MDT) Message-Id: <200007190313.VAA76846@harmony.village.org> To: obrien@FreeBSD.ORG Subject: Re: removal of kvtop() on i386 Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 18 Jul 2000 18:45:00 PDT." <20000718184500.E15761@dragon.nuxi.com> References: <20000718184500.E15761@dragon.nuxi.com> <20000717155552.A19233@cichlids.cichlids.com> <200007171828.LAA10544@mass.osd.bsdi.com> Date: Tue, 18 Jul 2000 21:13:04 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000718184500.E15761@dragon.nuxi.com> "David O'Brien" writes: : I have to agree with Mike. Please do not dirty the Alpha code with : obsoleted interfaces. The Alpha is a lot cleaner than our i386 code. Yes. Although the old pccard interface uses kvtop, it does so in a very bad way. It should bus_alloc_resource followed by a rman_get_vmaddr() for the stuff it does. It can't[*] use the DMA routines, because there's no DMA. Just the need to know where the device lives in bus space (so it can tell the device) and where it lives in virtual space (so it can access it). If one was really ambitious, one would convert the current direct access (via char *foo = vmaddr; *foo = blah;) with busspace (bus_read_1(...)). However, since that code is on its glide path to retirement, that might be too much work that would be better spend on other things. If the ed driver (or any other network driver) needs to access the memory directly, it should use the busspace routines to do it. In fact, since many of our network drivers don't use the busdma routines, it is very hard to get FreeBSD to run on an intel with > 4G of RAM (processors since the PPro have supported 36 or more address lines). kvtop is one of the things that is holding us back from doing that easily. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:14:23 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 827E637B5EA for ; Tue, 18 Jul 2000 20:14:21 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA89196; Tue, 18 Jul 2000 21:14:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA76870; Tue, 18 Jul 2000 21:14:11 -0600 (MDT) Message-Id: <200007190314.VAA76870@harmony.village.org> To: alex@big.endian.de (Alexander Langer) Subject: Re: removal of kvtop() on i386 Cc: Chuck Paterson , Poul-Henning Kamp , arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 17 Jul 2000 18:42:08 +0200." <20000717184208.B26484@cichlids.cichlids.com> References: <20000717184208.B26484@cichlids.cichlids.com> <200007171441.IAA22202@berserker.bsdi.com> Date: Tue, 18 Jul 2000 21:14:11 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000717184208.B26484@cichlids.cichlids.com> Alexander Langer writes: : Thus spake Chuck Paterson (cp@bsdi.com): : : > Has anybody though about how to change this for : > architectures like Sparc where the whole idea of handing : > a physical address to the drivers on a bus doesn't apply, and : > where a unmapping/cache flushing operation must be done : > at io completion. : : Uhm. Is that support for removing kvtop(), against removing kvtop() : or just a questions beside that topic? I'd take it as support :-) : How do other *BSDs do that? They use bus space and bus dma. I'd point you to man pages, but you'd have to be on a netbsd or openbsd system to use them :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:23:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F121337BAB5; Tue, 18 Jul 2000 20:23:33 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA89215; Tue, 18 Jul 2000 21:23:32 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA76910; Tue, 18 Jul 2000 21:23:23 -0600 (MDT) Message-Id: <200007190323.VAA76910@harmony.village.org> To: Greg Lehey Subject: Re: Tidying up the interrupt registration process Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG In-reply-to: Your message of "Mon, 17 Jul 2000 16:30:38 +0930." <20000717163038.J26231@wantadilla.lemis.com> References: <20000717163038.J26231@wantadilla.lemis.com> Date: Tue, 18 Jul 2000 21:23:23 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000717163038.J26231@wantadilla.lemis.com> Greg Lehey writes: : I think I now understand how drivers register interrupts with newbus, : and it seems that some tidying up is in order. Yes. : These flag bits are all lightly used, and there's confusing : duplication of functionality. For example, in nexus_setup_intr we : have: : : case (INTR_TYPE_TTY | INTR_TYPE_FAST): : mask = &tty_imask; : icflags |= INTR_FAST; This code is wrong. It should be moved out of the case statement. BDE posted a fix that I thought I'd committed, but it appears that I haven't done so yet. : It seems to me that we should define the flags to the *setup_intr : functions to match those in struct intrec. Probably the RF_* flags : are different enough in purpose that we shouldn't do the same thing : there. I think that INTR_FAST is special enough to be the only one that needs help. : In addition, these flags will have to change a lot in the change to : threaded interrupts. First, I intend to add two additional flags to : struct intrec: : : #define INTR_HEAVY 0x00000002 /* heavyweight interrupt process */ : #define INTR_LIGHT 0x00000004 /* light weight interrupt thread */ : #define INTR_THREADED (INTR_LIGHT | INTR_HEAVY) /* any kind of interrupt thread */ : : This will allow us to let traditional interrupts, lightweight threads : and heavyweight processes to coexist; when the change is complete, we : may be able to let them go away. The INTR_TYPE_TTY and friends are a : different issue; at the moment I don't know if they're enough, but : probably we should replace them with a process priority. I'd be : grateful for any thoughts on these subjects. The INTR_TYPE_TTY interrupts, except fast ones, are masked as a unit. Likewise with the INTR_TYPE_NET, etc. The intent here is to provide assistance in serialization of access to crititical structures. When you do a splnet, all the net devices who have an interrupt have their interrupt blocked. : About fast interrupts, which currently seem to be used only by the sio : driver: they perform their entire work before reenabling interrupts, : and it's possible that we can keep them like that, though I haven't : looked at the code yet. Does anybody know any reason why we should : convert them to threaded interrupts? Yes. They are used by more than the sio driver. I use them in at least two pci drivers that I have written for hardware that has extreme latency requirements that normal interrupts cannot accomplish. This is the same sort of thing as the serial fifos. These have extremely hard requirements to be serviced in (on the order of micro seconds). The "upper half" of the serial driver harvests the characters from the serial line when it gets interrupts and uses splsofttty() to activate the lower half of the driver. These devices simply cannot tolerate scheduling delays at all, even very fast ones. pci modems are an interesting problem. You want to share an interrupt, but fast interrupts can't be shared. On sufficiently fast machines, it isn't an issue, but on slow machines you can easily lose characters because interrupts are masked for too long. Heavy VM load (eg swapping) seems to make this problem happen more often than even just simple heavy disk I/O, but I've not done extensive tests to draw boundaries around this problem. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:27:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 05DED37B84C for ; Tue, 18 Jul 2000 20:27:23 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA89236; Tue, 18 Jul 2000 21:27:18 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA76961; Tue, 18 Jul 2000 21:27:09 -0600 (MDT) Message-Id: <200007190327.VAA76961@harmony.village.org> To: Marcel Moolenaar Subject: Re: Multiple kernels / module search path Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 17 Jul 2000 22:09:44 PDT." <3973E698.B8D53F1F@cup.hp.com> References: <3973E698.B8D53F1F@cup.hp.com> Date: Tue, 18 Jul 2000 21:27:09 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3973E698.B8D53F1F@cup.hp.com> Marcel Moolenaar writes: : If we do want the support to install multiple kernels with the : installkernel target, we face the same problem. Say that we install the : first kernel as "kernel" with modules directory "/modules". The module : search path is correct in this case. Other kernels are installed as, : say, kernel.NAME. These kernels should have their modules directory be : set to "/modules.NAME". But we also have to make sure that their module : search path is adjusted properly. : : Question 2: Is the above naming scheme acceptable? : : Question 3: Should we change the order in which modules are searched to : /modules{.NAME}:/boot:/, where {.NAME} denotes the optional name suffix. : : Question 4: Do we want /modules in the search for kernels with a : non-zero name so that the search path will be : /modules.NAME:/modules:/boot:/ : : It's a bit cryptic at places, but I hope the general idea has been : communicated sufficiently. Your feedback is appreciated, : : BTW: My personal preference is "yes, yes, yes, no" :-) My answers would be "yes" "MAYBE" "yes" "no". But I'm a fan of having kernel always be called kernel. I'd install kernel directly into /modules. If I want to boot kernel.foo, then install kernel into /modules.foo and the load path becomes just /modules.foo:/boot, with / not being serched. If I type "boot kernel.foo" it should be enough for all this to happen. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:28:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B1BDD37BB11 for ; Tue, 18 Jul 2000 20:28:40 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA89252; Tue, 18 Jul 2000 21:28:39 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA76993; Tue, 18 Jul 2000 21:28:30 -0600 (MDT) Message-Id: <200007190328.VAA76993@harmony.village.org> To: Brooks Davis Subject: Re: Multiple kernels / module search path Cc: Marcel Moolenaar , arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 17 Jul 2000 23:03:51 PDT." <20000717230351.C6353@orion.ac.hmc.edu> References: <20000717230351.C6353@orion.ac.hmc.edu> <3973E698.B8D53F1F@cup.hp.com> Date: Tue, 18 Jul 2000 21:28:30 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000717230351.C6353@orion.ac.hmc.edu> Brooks Davis writes: : I agree with you except here (and you may be able to find a solution : here.) My problem with not doing this is that ports and third party : software that creates modules (vmware, etc) needs a place to put them, : and currently that's modules. While you could put them in /boot, that : seems ugly at best. Otherwise, I like ideas very much. I've been : wanting to build and install my custom kernel and GENERIC in one fell : swoop since {build|install}kernel was added. I don't think that we want to autmoatically do this. modules need to be verified as working with a given kernel before we go start and loading them automatically... I'm not saying, btw, that a user shouldn't be allowed to setup the search path with /modules in it, but it should be explicit, not implicit. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:39:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 5401437B5EA; Tue, 18 Jul 2000 20:39:18 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id NAA09314; Wed, 19 Jul 2000 13:09:07 +0930 (CST) (envelope-from grog) Date: Wed, 19 Jul 2000 13:09:07 +0930 From: Greg Lehey To: Warner Losh Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719130907.H12072@wantadilla.lemis.com> References: <20000717163038.J26231@wantadilla.lemis.com> <200007190323.VAA76910@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007190323.VAA76910@harmony.village.org> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 18 July 2000 at 21:23:23 -0600, Warner Losh wrote: > In message <20000717163038.J26231@wantadilla.lemis.com> Greg Lehey writes: >> These flag bits are all lightly used, and there's confusing >> duplication of functionality. For example, in nexus_setup_intr we >> have: >> >> case (INTR_TYPE_TTY | INTR_TYPE_FAST): >> mask = &tty_imask; >> icflags |= INTR_FAST; > > This code is wrong. It should be moved out of the case statement. > BDE posted a fix that I thought I'd committed, but it appears that I > haven't done so yet. I think this function needs to be completely rewritten in the course of the implementation of interrupt threads. It sort of works now, so I don't think we should touch it further until the threads are up and hobbling. >> In addition, these flags will have to change a lot in the change to >> threaded interrupts. First, I intend to add two additional flags to >> struct intrec: >> >> #define INTR_HEAVY 0x00000002 /* heavyweight interrupt process */ >> #define INTR_LIGHT 0x00000004 /* light weight interrupt thread */ >> #define INTR_THREADED (INTR_LIGHT | INTR_HEAVY) /* any kind of interrupt thread */ >> >> This will allow us to let traditional interrupts, lightweight threads >> and heavyweight processes to coexist; when the change is complete, we >> may be able to let them go away. The INTR_TYPE_TTY and friends are a >> different issue; at the moment I don't know if they're enough, but >> probably we should replace them with a process priority. I'd be >> grateful for any thoughts on these subjects. > > The INTR_TYPE_TTY interrupts, except fast ones, are masked as a unit. > Likewise with the INTR_TYPE_NET, etc. The intent here is to provide > assistance in serialization of access to crititical structures. When > you do a splnet, all the net devices who have an interrupt have their > interrupt blocked. Right, that's the current way things are done. This will change too, to be replaced by relative scheduling priorities. That's the more interesting question: how should they relate to each other? >> About fast interrupts, which currently seem to be used only by the sio >> driver: they perform their entire work before reenabling interrupts, >> and it's possible that we can keep them like that, though I haven't >> looked at the code yet. Does anybody know any reason why we should >> convert them to threaded interrupts? > > Yes. They are used by more than the sio driver. I use them in at > least two pci drivers that I have written for hardware that has > extreme latency requirements that normal interrupts cannot > accomplish. This is the same sort of thing as the serial fifos. > These have extremely hard requirements to be serviced in (on the order > of micro seconds). The "upper half" of the serial driver harvests the > characters from the serial line when it gets interrupts and uses > splsofttty() to activate the lower half of the driver. These devices > simply cannot tolerate scheduling delays at all, even very fast ones. That's what I thought. Does anybody else see a reason to convert fast interrupts into threads? > pci modems are an interesting problem. You want to share an > interrupt, but fast interrupts can't be shared. On sufficiently > fast machines, it isn't an issue, but on slow machines you can > easily lose characters because interrupts are masked for too long. > Heavy VM load (eg swapping) seems to make this problem happen more > often than even just simple heavy disk I/O, but I've not done > extensive tests to draw boundaries around this problem. I can't see anything inherent in the treatment of fast interrupts which says they can't be shared. I'll take another look at the code; maybe we can get rid of this restriction. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:55:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id DC2BD37B7FE; Tue, 18 Jul 2000 20:55:22 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA21389; Tue, 18 Jul 2000 21:03:59 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007190403.VAA21389@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process In-reply-to: Your message of "Wed, 19 Jul 2000 13:09:07 +0930." <20000719130907.H12072@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 21:03:59 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The INTR_TYPE_TTY interrupts, except fast ones, are masked as a unit. > > Likewise with the INTR_TYPE_NET, etc. The intent here is to provide > > assistance in serialization of access to crititical structures. When > > you do a splnet, all the net devices who have an interrupt have their > > interrupt blocked. > > Right, that's the current way things are done. This will change too, > to be replaced by relative scheduling priorities. That's the more > interesting question: how should they relate to each other? As a general rule, they shouldn't. Don't get carried away with something relatively trivial like which interrupts should have "more" scheduling priority - just get them being scheduled at all for now. 8) > That's what I thought. Does anybody else see a reason to convert fast > interrupts into threads? No. Or more specifically, we need a mechanism for "classic-style" low-latency interrupt handlers. These will typically be coupled with a software-interrupt thread, more or less as they are now. > I can't see anything inherent in the treatment of fast interrupts > which says they can't be shared. I'll take another look at the code; > maybe we can get rid of this restriction. Sharing a 'fast' interrupt completely defeats the point of making it 'fast'. You should not be able to register a 'fast' handler on any source with anything else attached, nor anything else on a source that has a 'fast' handler already registered. Yes, this does impose some configuration constraints on the system, but there are few viable alternatives. -- ... 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] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:58: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9FDB937B7FE; Tue, 18 Jul 2000 20:57:58 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e6J3vuP14070; Tue, 18 Jul 2000 20:57:56 -0700 (PDT) Date: Tue, 18 Jul 2000 20:57:56 -0700 From: Alfred Perlstein To: Mike Smith Cc: Greg Lehey , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000718205756.Q13979@fw.wintelcom.net> References: <20000719130907.H12072@wantadilla.lemis.com> <200007190403.VAA21389@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200007190403.VAA21389@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Tue, Jul 18, 2000 at 09:03:59PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mike Smith [000718 20:55] wrote: > > Sharing a 'fast' interrupt completely defeats the point of making it > 'fast'. You should not be able to register a 'fast' handler on any > source with anything else attached, nor anything else on a source that > has a 'fast' handler already registered. Yes, this does impose some > configuration constraints on the system, but there are few viable > alternatives. Just wondering, could a device fall back to non-fast mode if the hardware forced this sort of situation but still complain about it? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 20:59:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id E39E337B7FE; Tue, 18 Jul 2000 20:59:28 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA09445; Tue, 18 Jul 2000 21:58:57 -0600 (MDT) Message-Id: <200007190358.VAA09445@berserker.bsdi.com> To: Greg Lehey Cc: Warner Losh , arch@freebsd.org, smp@freebsd.org Subject: Re: Tidying up the interrupt registration process From: Chuck Paterson Date: Tue, 18 Jul 2000 21:58:57 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG }That's what I thought. Does anybody else see a reason to convert fast }interrupts into threads? The short answer is no, you absolutely don't want to convert them to fully instantiated threads, especially when you only have a heavy wait solution. There is another middle ground that is less clear, and it depends partially on what you deem a thread. If you just switch the stack pointer and curproc, but use spin locks and don't allow for a context switch are you converting it to a thread. At this point the statistical stuff will charge time properly to interrupts rather than user processes, or other kernel processes, you also don't have to worry about pathological cases blowing out the stack. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 21: 2:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 7610637BB20 for ; Tue, 18 Jul 2000 21:02:38 -0700 (PDT) (envelope-from brdavis@orion.ac.hmc.edu) Received: (from brdavis@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) id UAA06756; Tue, 18 Jul 2000 20:55:44 -0700 (PDT) Date: Tue, 18 Jul 2000 20:55:44 -0700 From: Brooks Davis To: Warner Losh Cc: Brooks Davis , Marcel Moolenaar , arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path Message-ID: <20000718205544.A5801@orion.ac.hmc.edu> References: <20000717230351.C6353@orion.ac.hmc.edu> <3973E698.B8D53F1F@cup.hp.com> <20000717230351.C6353@orion.ac.hmc.edu> <200007190328.VAA76993@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <200007190328.VAA76993@harmony.village.org>; from imp@village.org on Tue, Jul 18, 2000 at 09:28:30PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 18, 2000 at 09:28:30PM -0600, Warner Losh wrote: > I don't think that we want to autmoatically do this. modules need to > be verified as working with a given kernel before we go start and > loading them automatically... Isn't that the job of the versioning system or am I missing the point? > I'm not saying, btw, that a user shouldn't be allowed to setup the > search path with /modules in it, but it should be explicit, not > implicit. My concern is simply that there needs to be an easily identifiable place for third party (read binary only) drivers to by installed. The most straight-forward way to handle this is to provide one place to put them. With versioning in place it doesn't seem like all that much of a pipe dream for a user to be able to drop a binary driver into a -STABLE system and expect it to work (-current is obviously a whole different ballgame). I suppose it might actually be a fat binary with, say, INVARIANTS enabled and disabled versions, but that a new kernel/module installation scheme should not make this substantialy more difficult then it currently is. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 21: 7: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id D2BAA37BC7B; Tue, 18 Jul 2000 21:07:02 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA21470; Tue, 18 Jul 2000 21:15:53 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007190415.VAA21470@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process In-reply-to: Your message of "Tue, 18 Jul 2000 20:57:56 PDT." <20000718205756.Q13979@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 21:15:53 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Mike Smith [000718 20:55] wrote: > > > > Sharing a 'fast' interrupt completely defeats the point of making it > > 'fast'. You should not be able to register a 'fast' handler on any > > source with anything else attached, nor anything else on a source that > > has a 'fast' handler already registered. Yes, this does impose some > > configuration constraints on the system, but there are few viable > > alternatives. > > Just wondering, could a device fall back to non-fast mode if the > hardware forced this sort of situation but still complain about it? You don't typically bother requesting a 'fast' interrupt unless you really need it. This decision would have to be left up to the device driver - some might be OK accepting the tradeoff (eg. sio), wheras for others this might constitute a fatal error. -- ... 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] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 21:22:12 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 8194337B99B; Tue, 18 Jul 2000 21:22:06 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id NAA27189; Wed, 19 Jul 2000 13:51:50 +0930 (CST) (envelope-from grog) Date: Wed, 19 Jul 2000 13:51:49 +0930 From: Greg Lehey To: Chuck Paterson Cc: Warner Losh , arch@freebsd.org, smp@freebsd.org Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719135149.I12072@wantadilla.lemis.com> References: <200007190358.VAA09445@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007190358.VAA09445@berserker.bsdi.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 18 July 2000 at 21:58:57 -0600, Chuck Paterson wrote: > > }That's what I thought. Does anybody else see a reason to convert fast > }interrupts into threads? > > The short answer is no, you absolutely don't want to > convert them to fully instantiated threads, especially when you > only have a heavy wait solution. There is another middle ground > that is less clear, and it depends partially on what you deem a > thread. If you just switch the stack pointer and curproc, but use > spin locks and don't allow for a context switch are you converting > it to a thread. At this point the statistical stuff will charge > time properly to interrupts rather than user processes, or other > kernel processes, you also don't have to worry about pathological > cases blowing out the stack. Does BSD/OS have fast interrupts? I haven't seen any evidence. In FreeBSD, a fast interrupt runs before EOI, so we can't convert it to a thread. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 21:27:38 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id B2B6437BB4C; Tue, 18 Jul 2000 21:27:31 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id NAA29575; Wed, 19 Jul 2000 13:57:30 +0930 (CST) (envelope-from grog) Date: Wed, 19 Jul 2000 13:57:30 +0930 From: Greg Lehey To: Mike Smith Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719135730.J12072@wantadilla.lemis.com> References: <20000719130907.H12072@wantadilla.lemis.com> <200007190403.VAA21389@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007190403.VAA21389@mass.osd.bsdi.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 18 July 2000 at 21:03:59 -0700, Mike Smith wrote: >>> The INTR_TYPE_TTY interrupts, except fast ones, are masked as a unit. >>> Likewise with the INTR_TYPE_NET, etc. The intent here is to provide >>> assistance in serialization of access to crititical structures. When >>> you do a splnet, all the net devices who have an interrupt have their >>> interrupt blocked. >> >> Right, that's the current way things are done. This will change too, >> to be replaced by relative scheduling priorities. That's the more >> interesting question: how should they relate to each other? > > As a general rule, they shouldn't. Don't get carried away with something > relatively trivial like which interrupts should have "more" scheduling > priority - just get them being scheduled at all for now. 8) That doesn't mean we shouldn't be thinking about the next step. >> I can't see anything inherent in the treatment of fast interrupts >> which says they can't be shared. I'll take another look at the code; >> maybe we can get rid of this restriction. > > Sharing a 'fast' interrupt completely defeats the point of making it > 'fast'. No, it partially defeats it. It's a tradeoff. > You should not be able to register a 'fast' handler on any source > with anything else attached, nor anything else on a source that has > a 'fast' handler already registered. Yes, this does impose some > configuration constraints on the system, but there are few viable > alternatives. You haven't really explained that. Sure, if you have more than one interrupt on an IRQ, it will take longer, but it will still ensure that nothing else interrupts in the meantime. You can't compare this to the current fast interrupt scheme which limits you to one interrupt handler, because the hardware reality isn't like that. You need to compare it to the alternative of a shared slow interrupt handler: clearly a fast interrupt handler will still be faster. And Warner produced a valid example of where it would make a difference. As regards sharing fast and slow interrupts on the same IRQ: I can see reasons for wanting to do this as well. I don't want to have to write the code, though :-) Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 21:37:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id A437F37B99B; Tue, 18 Jul 2000 21:37:09 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id OAA33609; Wed, 19 Jul 2000 14:07:07 +0930 (CST) (envelope-from grog) Date: Wed, 19 Jul 2000 14:07:07 +0930 From: Greg Lehey To: Mike Smith Cc: Alfred Perlstein , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719140707.K12072@wantadilla.lemis.com> References: <20000718205756.Q13979@fw.wintelcom.net> <200007190415.VAA21470@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007190415.VAA21470@mass.osd.bsdi.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 18 July 2000 at 21:15:53 -0700, Mike Smith wrote: >> * Mike Smith [000718 20:55] wrote: >>> >>> Sharing a 'fast' interrupt completely defeats the point of making it >>> 'fast'. You should not be able to register a 'fast' handler on any >>> source with anything else attached, nor anything else on a source that >>> has a 'fast' handler already registered. Yes, this does impose some >>> configuration constraints on the system, but there are few viable >>> alternatives. >> >> Just wondering, could a device fall back to non-fast mode if the >> hardware forced this sort of situation but still complain about it? > > You don't typically bother requesting a 'fast' interrupt unless you > really need it. This decision would have to be left up to the > device driver - some might be OK accepting the tradeoff (eg. sio), > wheras for others this might constitute a fatal error. In fact, unless I'm missing something, it looks as if there's no code there to stop you from sharing fast interrupts. I could have sworn there was, but the code in intr_machdep.c doesn't check. The cy driver also sets INTR_EXCL, which is checked for, but nexus_setup_intr doesn't. If you share a fast interrupt and a slow interrupt, the first-level handler becomes the mux, and so it appears that the "fast" attribute would just go away, *without* any warning. I don't know if there's something else that would stop it from working at all. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 21:41:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id 531AF37BC88; Tue, 18 Jul 2000 21:41:38 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA21651; Tue, 18 Jul 2000 21:49:32 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007190449.VAA21651@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process In-reply-to: Your message of "Wed, 19 Jul 2000 13:57:30 +0930." <20000719135730.J12072@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 21:49:32 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You should not be able to register a 'fast' handler on any source > > with anything else attached, nor anything else on a source that has > > a 'fast' handler already registered. Yes, this does impose some > > configuration constraints on the system, but there are few viable > > alternatives. > > You haven't really explained that. Sure, if you have more than one > interrupt on an IRQ, it will take longer, but it will still ensure > that nothing else interrupts in the meantime. You can't compare this > to the current fast interrupt scheme which limits you to one interrupt > handler, because the hardware reality isn't like that. You need to > compare it to the alternative of a shared slow interrupt handler: > clearly a fast interrupt handler will still be faster. And Warner > produced a valid example of where it would make a difference. This is not correct. There are two separate things that a 'fast' interrupt handler seeks to achieve: reduced and constrained interrupt latency. Allowing 'fast' interrupts to be shared removes any hope of constraining latency, as well as increasing it. Note also that a 'fast' handler may be computationally expensive - the 'fast' criterion has to do with how it is invoked, not how it runs. > As regards sharing fast and slow interrupts on the same IRQ: I can see > reasons for wanting to do this as well. I don't want to have to write > the code, though :-) It would be relatively trivial, actually, since the dispatcher that invokes the actual interrupt thread in the 'not-fast' case is really a 'fast' interrupt handler. -- ... 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] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 21:53:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 682A937B99B; Tue, 18 Jul 2000 21:53:40 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id OAA40543; Wed, 19 Jul 2000 14:23:37 +0930 (CST) (envelope-from grog) Date: Wed, 19 Jul 2000 14:23:37 +0930 From: Greg Lehey To: Mike Smith Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719142337.L12072@wantadilla.lemis.com> References: <20000719135730.J12072@wantadilla.lemis.com> <200007190449.VAA21651@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007190449.VAA21651@mass.osd.bsdi.com> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 18 July 2000 at 21:49:32 -0700, Mike Smith wrote: >>> You should not be able to register a 'fast' handler on any source >>> with anything else attached, nor anything else on a source that has >>> a 'fast' handler already registered. Yes, this does impose some >>> configuration constraints on the system, but there are few viable >>> alternatives. >> >> You haven't really explained that. Sure, if you have more than one >> interrupt on an IRQ, it will take longer, but it will still ensure >> that nothing else interrupts in the meantime. You can't compare this >> to the current fast interrupt scheme which limits you to one interrupt >> handler, because the hardware reality isn't like that. You need to >> compare it to the alternative of a shared slow interrupt handler: >> clearly a fast interrupt handler will still be faster. And Warner >> produced a valid example of where it would make a difference. > > This is not correct. You need to be more specific in "this". > There are two separate things that a 'fast' interrupt handler seeks > to achieve: reduced and constrained interrupt latency. Right. > Allowing 'fast' interrupts to be shared removes any hope of > constraining latency, as well as increasing it. You're being rather categorical there. As I said, it's a tradeoff. > Note also that a 'fast' handler may be computationally expensive - > the 'fast' criterion has to do with how it is invoked, not how it > runs. Indeed. Much of your hope lies in the wise use of the resource. In fact, I'm astounded how much code there is in siointerrupt. >> As regards sharing fast and slow interrupts on the same IRQ: I can see >> reasons for wanting to do this as well. I don't want to have to write >> the code, though :-) > > It would be relatively trivial, actually, since the dispatcher that > invokes the actual interrupt thread in the 'not-fast' case is really a > 'fast' interrupt handler. No, that's not correct. You set a fast interrupt in icu_setup() by passing the INTR_FAST flag. Slightly simplified: int icu_setup(int intr, inthand2_t *handler, void *arg, u_int *maskptr, int flags) { ... if (flags & INTR_FAST) { vector = TPR_FAST_INTS + intr; setidt(vector, fastintr[intr], SDT_SYS386IGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); } else { vector = TPR_SLOW_INTS + intr; setidt(vector, slowintr[intr], SDT_SYS386IGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); The call to set the mux (in add_intrdesc) is: if (icu_setup(irq, intr_mux, head, 0, 0) != 0) return (-1); So it's a slow interrupt. But you might be right that it would be easier to do than I thought. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 22:59: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CA68A37BCE2; Tue, 18 Jul 2000 22:58:55 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA89830; Tue, 18 Jul 2000 23:58:53 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA77880; Tue, 18 Jul 2000 23:58:43 -0600 (MDT) Message-Id: <200007190558.XAA77880@harmony.village.org> To: Greg Lehey Subject: Re: Tidying up the interrupt registration process Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG In-reply-to: Your message of "Wed, 19 Jul 2000 13:09:07 +0930." <20000719130907.H12072@wantadilla.lemis.com> References: <20000719130907.H12072@wantadilla.lemis.com> <20000717163038.J26231@wantadilla.lemis.com> <200007190323.VAA76910@harmony.village.org> Date: Tue, 18 Jul 2000 23:58:43 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000719130907.H12072@wantadilla.lemis.com> Greg Lehey writes: : I think this function needs to be completely rewritten in the course : of the implementation of interrupt threads. It sort of works now, so : I don't think we should touch it further until the threads are up and : hobbling. I want to fix the fast interrupt part of it. : That's what I thought. Does anybody else see a reason to convert fast : interrupts into threads? So long as they run with the lowest possible latency, that would be OK. : > pci modems are an interesting problem. You want to share an : > interrupt, but fast interrupts can't be shared. On sufficiently : > fast machines, it isn't an issue, but on slow machines you can : > easily lose characters because interrupts are masked for too long. : > Heavy VM load (eg swapping) seems to make this problem happen more : > often than even just simple heavy disk I/O, but I've not done : > extensive tests to draw boundaries around this problem. : : I can't see anything inherent in the treatment of fast interrupts : which says they can't be shared. I'll take another look at the code; : maybe we can get rid of this restriction. I think it is an implementation thing, but bde will know better. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 23:13:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 8624B37BCD6; Tue, 18 Jul 2000 23:13:22 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id PAA73758; Wed, 19 Jul 2000 15:43:13 +0930 (CST) (envelope-from grog) Date: Wed, 19 Jul 2000 15:43:13 +0930 From: Greg Lehey To: Warner Losh Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719154313.M12072@wantadilla.lemis.com> References: <20000719130907.H12072@wantadilla.lemis.com> <20000717163038.J26231@wantadilla.lemis.com> <200007190323.VAA76910@harmony.village.org> <20000719130907.H12072@wantadilla.lemis.com> <200007190558.XAA77880@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007190558.XAA77880@harmony.village.org> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 18 July 2000 at 23:58:43 -0600, Warner Losh wrote: > In message <20000719130907.H12072@wantadilla.lemis.com> Greg Lehey writes: >> I think this function needs to be completely rewritten in the course >> of the implementation of interrupt threads. It sort of works now, so >> I don't think we should touch it further until the threads are up and >> hobbling. > > I want to fix the fast interrupt part of it. Well, I was lying when I said we wouldn't touch it. In the meantime, I've seen that the BSDi implementation has already addressed the question of priorities, and now we have no more interrupt masks, the mask parameter to inthand_add changes into a pri parameter. So the code you're talking about becomes: switch (flags) { case INTR_TYPE_TTY: pri = PI_TTYLOW; break; case (INTR_TYPE_TTY | INTR_FAST): pri = PI_TTYHIGH; break; The flags parameter also gets passed directly to inthand_add. >> That's what I thought. Does anybody else see a reason to convert fast >> interrupts into threads? > > So long as they run with the lowest possible latency, that would be > OK. See the discussion. It won't work like that. >>> pci modems are an interesting problem. You want to share an >>> interrupt, but fast interrupts can't be shared. On sufficiently >>> fast machines, it isn't an issue, but on slow machines you can >>> easily lose characters because interrupts are masked for too long. >>> Heavy VM load (eg swapping) seems to make this problem happen more >>> often than even just simple heavy disk I/O, but I've not done >>> extensive tests to draw boundaries around this problem. >> >> I can't see anything inherent in the treatment of fast interrupts >> which says they can't be shared. I'll take another look at the code; >> maybe we can get rid of this restriction. > > I think it is an implementation thing, but bde will know better. He's been very quiet lately. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 18 23:49:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mout2.silyn-tek.de (mout2.silyn-tek.de [194.25.165.70]) by hub.freebsd.org (Postfix) with ESMTP id 47A2037BCD6; Tue, 18 Jul 2000 23:49:25 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from [192.168.32.33] (helo=mx1.silyn-tek.de) by mout2.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EnfY-0006YG-00; Wed, 19 Jul 2000 08:49:24 +0200 Received: from p3e9c110f.dip0.t-ipconnect.de ([62.156.17.15] helo=neutron.cichlids.com) by mx1.silyn-tek.de with esmtp (Exim 3.13 #1) id 13EnfW-00079H-00; Wed, 19 Jul 2000 08:49:22 +0200 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id 3FF08AB91; Wed, 19 Jul 2000 08:50:59 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 7C34F14A6A; Wed, 19 Jul 2000 08:49:20 +0200 (CEST) Date: Wed, 19 Jul 2000 08:49:20 +0200 From: Alexander Langer To: David O'Brien Cc: arch@freebsd.org Subject: Re: removal of kvtop() on i386 Message-ID: <20000719084920.B3248@cichlids.cichlids.com> References: <20000717155552.A19233@cichlids.cichlids.com> <200007171828.LAA10544@mass.osd.bsdi.com> <20000718184500.E15761@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000718184500.E15761@dragon.nuxi.com>; from obrien@freebsd.org on Tue, Jul 18, 2000 at 06:45:00PM -0700 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake David O'Brien (obrien@freebsd.org): > > The 'ed' driver should be rewritten to use newbus/busspace, at which > > point kvtop stops being an issue. > I have to agree with Mike. Please do not dirty the Alpha code with > obsoleted interfaces. The Alpha is a lot cleaner than our i386 code. OK. I might take a look at it. Then - when all devices use busspace and noone uses kvtop() - kvtop() could be removed? Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 19 0:58:35 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id D68CB37BDC1; Wed, 19 Jul 2000 00:58:26 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id JAA02734; Wed, 19 Jul 2000 09:58:17 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Robert Watson , Warner Losh , Kelly Yancey , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) In-reply-to: Your message of "Tue, 18 Jul 2000 15:12:18 PDT." <3974D642.59E2B600@elischer.org> Date: Wed, 19 Jul 2000 09:58:17 +0200 Message-ID: <2732.963993497@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3974D642.59E2B600@elischer.org>, Julian Elischer writes: >> Your "symlink device node" proposal still doesn't solve the >> cloning problem, so it is only 1/2 a solution to what in >> practice is a non-problem. > >It allows the cloning devices to be represented >all over the filesystems rather than limitted to the devfs, >thus it allows them to be in chroot/jails without zillions >of devfs mounts... No it doesn't. You "symlink" idea just replaces the major+minor with a string, that's all. Cloning can be done two ways, which I will illustrate with the pty driver as example: A) You open "/dev/pty", which clones and does some h0h0magic with vnodes and fdesc. You call ioctl(fd, WHATSMYREALNAME, buf, sizeof(buf)) and it tells you that you are really "/dev/pty102". B) You try to open ("/dev/pty%d",N) for N [0...] Once an open succeeds you have your fd and your name. (this is what we do today) In scenario A) in a jail, we may not have a /dev/pty102 entry in /dev and we would have to try to create it. Creating device nodes in jails is a NO-NO thing, and adding h0h0magic code to allow this for ptys anyway is at best a gross hack. *This* is the cloning problem in jails. In scenario B) this is not a problem, but a configuration issue: you have to create sufficient many ptys when you setup the jail. Jails were never meant to be a 100% faithfull rendition of a FreeBSD system, and in particular emphasis was put on it being a lightweight implementation. If jails get in the way of something in the central core of FreeBSD, jails have to give way. Anyway, since we cannot make devfs mandatory right away anyway, we will have to leave th cdevsw[] around for a while. (It could be changed to use the "cloning-callback" and I may attempt to make it do that before anything else is done since that solves some issues with disks as well.) So I'm leaning heavily against model B) right now, since it gives us total backwards compatibility. >> >devfs as it is now has routines to do this.. >> >> No it hasn't, the vnode still has to be magically handled because >> it doesn't have a mountpoint. > >It Is magically handled. it would still have to be magically >handled in any scheme you've mentionned so far. No. Devfs can be mounted without calling namei. Once devfs is mounted, the root mount can use a normal namei and the device node will come out of a plain mount with no magic code. >> Your "SYMLINK-LINK" proposal offers nothing that we don't already >> have with major/minor identification, which for all intents >> and purposes we will have to retain compatibility with for quite >> some time anyway. > >We have pre-allocated major numbers. One of the MAIN aims >of devfs was to make ALL devices dynamically loadable, >which implies not limitting yourself to >preallocated numbers. I agree that this is a laudable goal, but right now it doesn't help us, and consequently I would rather postpone it until we are over the first hurdle, rather than put more spices in the pot at this time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 19 1:28:22 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id D0BC837BDE4 for ; Wed, 19 Jul 2000 01:28:17 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id KAA43169; Wed, 19 Jul 2000 10:33:36 +0200 (CEST) (envelope-from adrian) Date: Wed, 19 Jul 2000 10:33:36 +0200 From: Adrian Chadd To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) Message-ID: <20000719103336.B40749@ywing.creative.net.au> References: <3974D642.59E2B600@elischer.org> <2732.963993497@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <2732.963993497@critter.freebsd.dk>; from phk@critter.freebsd.dk on Wed, Jul 19, 2000 at 09:58:17AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [To/CC list chomped because I think we're all on -arch anyway] On Wed, Jul 19, 2000, Poul-Henning Kamp wrote: > In message <3974D642.59E2B600@elischer.org>, Julian Elischer writes: > > >> Your "symlink device node" proposal still doesn't solve the > >> cloning problem, so it is only 1/2 a solution to what in > >> practice is a non-problem. > > > >It allows the cloning devices to be represented > >all over the filesystems rather than limitted to the devfs, > >thus it allows them to be in chroot/jails without zillions > >of devfs mounts... > > No it doesn't. You "symlink" idea just replaces the major+minor > with a string, that's all. > > Cloning can be done two ways, which I will illustrate with the pty > driver as example: > > A) You open "/dev/pty", which clones and does some h0h0magic > with vnodes and fdesc. > You call ioctl(fd, WHATSMYREALNAME, buf, sizeof(buf)) > and it tells you that you are really "/dev/pty102". > > B) You try to open ("/dev/pty%d",N) for N [0...] > Once an open succeeds you have your fd and your name. > (this is what we do today) The amount of h0h0magick needed for A from a vnode point of view really isn't that much. In fact, if you wanted to make it less evil you could mandate that stat.st_ino or even stat.st_dev reflects the device minor number when you're cloning, which seems a lot neater than the above ioctl(). (I used stat.st_ino when implementing the cloning creation file in my inode FS FFS hack.) 2c, adrian -- Adrian Chadd Build a man a fire, and he's warm for the rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 19 1:29: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ywing.creative.net.au (ywing.creative.net.au [203.56.168.34]) by hub.freebsd.org (Postfix) with ESMTP id 7588937BDE4; Wed, 19 Jul 2000 01:29:06 -0700 (PDT) (envelope-from adrian@ywing.creative.net.au) Received: (from adrian@localhost) by ywing.creative.net.au (8.9.3/8.9.3) id KAA43179; Wed, 19 Jul 2000 10:34:18 +0200 (CEST) (envelope-from adrian) Date: Wed, 19 Jul 2000 10:34:18 +0200 From: Adrian Chadd To: Poul-Henning Kamp Cc: Julian Elischer , Robert Watson , Warner Losh , Kelly Yancey , Dan Nelson , Adrian Chadd , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) Message-ID: <20000719103418.C40749@ywing.creative.net.au> References: <3974D642.59E2B600@elischer.org> <2732.963993497@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <2732.963993497@critter.freebsd.dk>; from phk@critter.freebsd.dk on Wed, Jul 19, 2000 at 09:58:17AM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 19, 2000, Poul-Henning Kamp wrote: > In message <3974D642.59E2B600@elischer.org>, Julian Elischer writes: > > >> Your "symlink device node" proposal still doesn't solve the > >> cloning problem, so it is only 1/2 a solution to what in > >> practice is a non-problem. [snip] Could I please ask anyone in the above CC list who isn't on -arch to subscribe to the list? Pretty please? :-P Adrian -- Adrian Chadd Build a man a fire, and he's warm for the rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 19 8:15:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D494737BDDC; Wed, 19 Jul 2000 08:15:36 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id BAA28186; Thu, 20 Jul 2000 01:15:15 +1000 Date: Thu, 20 Jul 2000 01:15:08 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Greg Lehey Cc: Mike Smith , Alfred Perlstein , arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process In-Reply-To: <20000719140707.K12072@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 19 Jul 2000, Greg Lehey wrote: > On Tuesday, 18 July 2000 at 21:15:53 -0700, Mike Smith wrote: > >> * Mike Smith [000718 20:55] wrote: > >>> > >>> Sharing a 'fast' interrupt completely defeats the point of making it > >>> 'fast'. You should not be able to register a 'fast' handler on any > >>> source with anything else attached, nor anything else on a source that > >>> has a 'fast' handler already registered. Yes, this does impose some > >>> configuration constraints on the system, but there are few viable > >>> alternatives. Not quite. Attaching multiple fast interrupt handlers to the same irq is not much different from attaching them to different irqs. The handlers should be executed serially in the !SMP case and on different CPUs (serially per CPU) in the SMP case. This is currently not implemented. Sharing the irq is only undesirable (in the all-fast case) because it adds overheads for polling all the devices. Attaching a mixture of fast and normal handlers to the same irq seems to be impossible to implement. If interrupts are edge triggered, then we don't need to touch the PIC masks currently do in the i386 !SMP case (I'm not sure about other cases), but we won't see new interrupts for fast devices on the same irq while we are handling normal interrupts. This defeats the point of using fast interrupts. If interrupts are level triggered, then we must set the PIC masks to prevent endless interrupts, and again we won't see fast interrupts whule handling normal ones. > >> Just wondering, could a device fall back to non-fast mode if the > >> hardware forced this sort of situation but still complain about it? > > > > You don't typically bother requesting a 'fast' interrupt unless you > > really need it. This decision would have to be left up to the > > device driver - some might be OK accepting the tradeoff (eg. sio), > > wheras for others this might constitute a fatal error. The sio and cy drivers strongly prefer to use fast interrupts. The sio driver just falls back to using no interrupts if it can't attach a fast interrupt. The cy driver falls back to normal interrupt and gives up if it can't attach either type. Support for falling back is still deficient. The fallback may need to be done later when another device that requires the non-preferred type is attached. > In fact, unless I'm missing something, it looks as if there's no code > there to stop you from sharing fast interrupts. I could have sworn > there was, but the code in intr_machdep.c doesn't check. The cy This is a bug. Sharing of fast interrupts is possible but is not implemented. Drivers shouldn't need to know this. > driver also sets INTR_EXCL, which is checked for, but nexus_setup_intr > doesn't. If you share a fast interrupt and a slow interrupt, the > first-level handler becomes the mux, and so it appears that the "fast" > attribute would just go away, *without* any warning. I don't know if > there's something else that would stop it from working at all. I think implementation of sharing of fast interrupt handlers only requires a different mux that doesn't call spl*() and is attached as a fast handler. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 19 14:21: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 12DA537BE86 for ; Wed, 19 Jul 2000 14:20:53 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA94159; Wed, 19 Jul 2000 15:20:42 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA84757; Wed, 19 Jul 2000 15:20:40 -0600 (MDT) Message-Id: <200007192120.PAA84757@harmony.village.org> To: Bob Bishop Subject: Re: Bikesheds Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 18 Jul 2000 13:36:28 BST." References: Your message of "17 Jul 2000 21:55:29 +0200." Date: Wed, 19 Jul 2000 15:20:40 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Bob Bishop writes: : A metabikeshed discussion, on the other hand, is one where the protagonists I want to have a metametabikeshed metadiscussion. :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 19 16:27:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id E354D37B764 for ; Wed, 19 Jul 2000 16:27:02 -0700 (PDT) (envelope-from lefevre@citeweb.net) Received: (qmail 1679143 invoked from network); 19 Jul 2000 23:27:01 -0000 Received: from r224m65.cybercable.tm.fr (HELO gits.dyndns.org) ([195.132.224.65]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 19 Jul 2000 23:27:01 -0000 Received: (from root@localhost) by gits.dyndns.org (8.9.3/8.9.3) id BAA68960; Thu, 20 Jul 2000 01:26:56 +0200 (CEST) (envelope-from lefevre@citeweb.net) Posted-Date: Thu, 20 Jul 2000 01:26:56 +0200 (CEST) To: Marcel Moolenaar Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path References: <200007182113.OAA18973@mass.osd.bsdi.com> <3974CB11.388FE532@cup.hp.com> Reply-To: clefevre@citeweb.net X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C From: Cyrille Lefevre To-List: freebsd-arch@freebsd.org Date: 20 Jul 2000 01:26:55 +0200 In-Reply-To: Marcel Moolenaar's message of "Tue, 18 Jul 2000 14:24:33 -0700" Message-ID: Lines: 48 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar writes: > Mike Smith wrote: > > > > > The problem is with versioning. If I add 3rd party module foo.ko to > > > modules, while it actually is a module for kernel 'kernel.bar' *and* > > > kernel and kernel.bar are sufficiently incompatible, then kernel won't > > > boot (for example) if the module is loaded at boot time. > > > > > > Or, if kernel.bar is booted and I want to load foo.ko, I might pick up > > > the version from /modules if I don't happen to have a foo.ko in > > > /modules.bar, which may be sufficiently incompatible and cause a kernel > > > panic. > > > > This has already been discussed to death, and consensus has been as > > follows: > [snip] > > Ok, I'll make {build|install}kernel behave the same as the traditional > way only and not add the ability to install multiple kernels. We can > always revisit these targets when the improved infrastructure is in > place. there is one thing I don't understand in this thread. you are saying than modules are different from kernel to kernel. I suppose this is true if you build modules as part of world (the old way) and not as part of the kernel. where, if the src tree as been updated between the workd and the kernel. I'm right ? if you build the world and the kernel in the same time, even if you have multiple kernels (read your own and GENERIC), it should not be a problem to have one and only one module directory. do you understand what I mean ? and what I understand is that the building of modules as part of the kernel and not of the world is to avoid conflicts if the src tree has been updated. IMHO, to left the root directory clean, it would be better to create /modules/WHATEVER subdirectories than /modules.WHATEVER. the idea to have kernel.ko in /modules/WHATEVER is interresting. what is the problem about to have /:/boot:/modules/WHATEVER:/modules as the modules search path ? another problem is to say to the boot loader which kernel to load. what about loader_conf_files=" \ /boot/boot.conf /boot/loader.conf /boot/loader.conf.local" where boot.conf just contain kernel="/modules/WHATEVER/kernel" which is updated a kernel installation ? Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 19 16:41:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id EAE8437B816 for ; Wed, 19 Jul 2000 16:41:45 -0700 (PDT) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id 7900D112F; Wed, 19 Jul 2000 16:41:45 -0700 (PDT) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id QAA25378; Wed, 19 Jul 2000 16:41:44 -0700 (PDT) Message-ID: <39763CB9.89DFA18C@cup.hp.com> Date: Wed, 19 Jul 2000 16:41:45 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: clefevre@citeweb.net Cc: arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path References: <200007182113.OAA18973@mass.osd.bsdi.com> <3974CB11.388FE532@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cyrille Lefevre wrote: > > there is one thing I don't understand in this thread. > you are saying than modules are different from kernel to kernel. Kernels and their modules can be completely different. Take for example an upgrade from 4-stable to 5-current. > I suppose this is true if you build modules as part of world (the > old way) and not as part of the kernel. where, if the src tree > as been updated between the workd and the kernel. I'm right ? I'm not talking about kernel vs. module differences (ie kernel and modules being out of sync). > if you build the world and the kernel in the same time, even if > you have multiple kernels (read your own and GENERIC), it should > not be a problem to have one and only one module directory. Correct, but the kernel that was in the root was build earlier and my be incompatible with the one that's being installed. > do you understand what I mean ? and what I understand is that > the building of modules as part of the kernel and not of the world > is to avoid conflicts if the src tree has been updated. It's to avoid conflicts between a kernel and its modules. Not between 2 different kernels and their modules. > what is the problem about to have /:/boot:/modules/WHATEVER:/modules > as the modules search path ? Interference. I guess we'll discuss all these issues when the new infrastructure is being deployed, if it needs any more discussing, of course. There's no point in discussing this any further here, because we're not going to worry about multiple kernels now. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jul 19 20:51:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id 436B437B6A3 for ; Wed, 19 Jul 2000 20:51:37 -0700 (PDT) (envelope-from root@gits.dyndns.org) Received: (qmail 1766040 invoked from network); 20 Jul 2000 03:51:35 -0000 Received: from r224m65.cybercable.tm.fr (HELO gits.dyndns.org) ([195.132.224.65]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 20 Jul 2000 03:51:35 -0000 Received: (from root@localhost) by gits.dyndns.org (8.9.3/8.9.3) id FAA71019; Thu, 20 Jul 2000 05:51:35 +0200 (CEST) (envelope-from root) From: Cyrille Lefevre Posted-Date: Thu, 20 Jul 2000 05:51:35 +0200 (CEST) Message-Id: <200007200351.FAA71019@gits.dyndns.org> Subject: Re: Multiple kernels / module search path In-Reply-To: <39763CB9.89DFA18C@cup.hp.com> "from Marcel Moolenaar at Jul 19, 2000 04:41:45 pm" To: Marcel Moolenaar Date: Thu, 20 Jul 2000 05:51:35 +0200 (CEST) Cc: arch@FreeBSD.ORG Reply-To: clefevre@citeweb.net Organization: ACME X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > Cyrille Lefevre wrote: > > > > there is one thing I don't understand in this thread. > > you are saying than modules are different from kernel to kernel. > > Kernels and their modules can be completely different. Take for example > an upgrade from 4-stable to 5-current. I'm not right w/ you. when you do an upgrade, you build the world, then the kernel (using buildkernel). so, all is in sync, no ? > > do you understand what I mean ? and what I understand is that > > the building of modules as part of the kernel and not of the world > > is to avoid conflicts if the src tree has been updated. > > It's to avoid conflicts between a kernel and its modules. Not between 2 > different kernels and their modules. ok, that's what I understood until now :) so, for instance, the buildkernel target could be modified to build modules only for the first kernel, not for the others. do you see what I mean ? if I said KERNEL="WHATEVER GENERIC" in /etc/make.conf, modules are build twince and it's a lost of time :( > > what is the problem about to have /:/boot:/modules/WHATEVER:/modules > > as the modules search path ? > > Interference. > > I guess we'll discuss all these issues when the new infrastructure is > being deployed, if it needs any more discussing, of course. There's no > point in discussing this any further here, because we're not going to > worry about multiple kernels now. humm! I always keep a GENERIC kernel in sync, just in case... that's why I build more than one kernel. FYI, yesterday, in -stable, I post a Super-Makefile to cvsup/(update)/\ build/install everything from one point. I use it for month w/o any problems. it's a little bit complicated, but I have no choice. see you. Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 21 13:58:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2E95537BCFC for ; Fri, 21 Jul 2000 13:58:52 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA14298 for ; Fri, 21 Jul 2000 13:58:51 -0700 Date: Fri, 21 Jul 2000 13:58:30 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: freebsd-arch@freebsd.org Subject: How much do we need the all-singing, all-dancing devfs? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It occurred to me that for at least what *I'm* interested in devfs for, that I may not actually need it. The portion I've always been interested in has been the location of unlabelled mass storage- disks. They can be known via VPD info (drive serial numbers) or via WWN (world wide names). Their physical bus 'address', particularly for Fibre Channel can change a lot, so the probe order in which they're seen causes them to show as differnt da units. We can guarantee that this won't change until a reboot (modulo the 'pack invalidation' issue- which is a separate issue). Given this, it's really a name translation issue to find out which da instance is which World Wide Name so and so. For example, I have: isp2: Target 0 (Loop 0x0) Port ID 0xef role Target arrived Port WWN 0x21000020370752ba Node WWN 0x20000020370752ba Which then probes as: pass9 at isp2 bus 0 target 0 lun 0 pass9: Fixed Direct Access SCSI-2 device pass9: Serial Number LAE84063 pass9: 100.000MB/s transfers, Tagged Queueing Enabled da6 at isp2 bus 0 target 0 lun 0 da6: Fixed Direct Access SCSI-2 device da6: Serial Number LAE84063 da6: 100.000MB/s transfers, Tagged Queueing Enabled da6: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) It wouldn't be much extra work to be able to pass the WWN info up through CAM, so that, e.g., libcam, could fetch it. As a taste test, how would modifying mount to understand WWNs && serial numbers and do the appropriate translation to get the current 'da' instance number feel for people? This way, you might have something like fcwwn@0x21000020370752ba,0 / ufs rw 1 1 or scsidsn@"LAE84063",0 /space ufs rw 0 0 [ the trailing ',X' is a lun qualifier ] This way, we can really do SAN stuff *without* a full blown devfs. Thoughts? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 21 14:56:57 2000 Delivered-To: freebsd-arch@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 824DE37C112 for ; Fri, 21 Jul 2000 14:56:49 -0700 (PDT) (envelope-from wkb@freebie.demon.nl) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 13Fkmj-0003GC-01; Fri, 21 Jul 2000 21:56:46 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.9.3/8.9.3) id XAA22039; Fri, 21 Jul 2000 23:39:03 +0200 (CEST) (envelope-from wkb) Date: Fri, 21 Jul 2000 23:39:03 +0200 From: Wilko Bulte To: Matthew Jacob Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? Message-ID: <20000721233903.A21976@freebie.demon.nl> Reply-To: wilko@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mjacob@feral.com on Fri, Jul 21, 2000 at 01:58:30PM -0700 X-OS: FreeBSD 4.1-RC X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 21, 2000 at 01:58:30PM -0700, Matthew Jacob wrote: > The portion I've always been interested in has been the location of unlabelled > mass storage- disks. They can be known via VPD info (drive serial numbers) or > via WWN (world wide names). Their physical bus 'address', particularly for > Fibre Channel can change a lot, so the probe order in which they're seen > causes them to show as differnt da units. We can guarantee that this won't > change until a reboot (modulo the 'pack invalidation' issue- which is a > separate issue). > > Given this, it's really a name translation issue to find out which da instance > is which World Wide Name so and so. For example, I have: > > isp2: Target 0 (Loop 0x0) Port ID 0xef role Target arrived > Port WWN 0x21000020370752ba > Node WWN 0x20000020370752ba These are 64 bit WWNs. For example the CPQ HSGxx StorageWorks arrays present a 128 bit extended WWN for each of the LUNs they can present to the FC-AL/fabric they are connected to. A total of 128 LUNs can be presented via 2 host port pairs (a pair of ports acts as a failover pair in case one has redundant array controllers; of each controller one port is part of one pair). Serial numbers (IIRC) that are presented by a LUN are all the same: the ser# of the HSG raid controller. And are therefore quite useless to the problem at hand. So, I think it would be nice if 128 bit WWN could also be handled. A, very desirable IMO, side effect is that once this is done correctly one can use the information for use in a dual-rail driver. For HA systems having a dual connection to a RAID box becomes rather common these days. Using the WWNs it is relatively easy to spot multiple paths to a single LUN/disk. > Which then probes as: > > pass9 at isp2 bus 0 target 0 lun 0 > pass9: Fixed Direct Access SCSI-2 device > pass9: Serial Number LAE84063 > pass9: 100.000MB/s transfers, Tagged Queueing Enabled > da6 at isp2 bus 0 target 0 lun 0 > da6: Fixed Direct Access SCSI-2 device > da6: Serial Number LAE84063 > da6: 100.000MB/s transfers, Tagged Queueing Enabled > da6: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) > > > It wouldn't be much extra work to be able to pass the WWN info up through CAM, > so that, e.g., libcam, could fetch it. > > As a taste test, how would modifying mount to understand WWNs && serial > numbers and do the appropriate translation to get the current 'da' instance > number feel for people? This way, you might have something like > > fcwwn@0x21000020370752ba,0 / ufs rw 1 1 > > or > > scsidsn@"LAE84063",0 /space ufs rw 0 0 > > [ the trailing ',X' is a lun qualifier ] > > This way, we can really do SAN stuff *without* a full blown devfs. The problem I see is the fact that I have yet to meet someone who can correctly transcribe 64 bit numbers, let alone 128bit ones.. :-( But there is only so much you can do about that problem. W/ -- Wilko Bulte http://www.freebsd.org wilko@freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 21 15: 4:14 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1B8D137C171; Fri, 21 Jul 2000 15:04:11 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA14751; Fri, 21 Jul 2000 15:03:49 -0700 Date: Fri, 21 Jul 2000 15:03:27 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: wilko@freebsd.org Cc: freebsd-arch@freebsd.org Subject: Re: How much do we need the all-singing, all-dancing devfs? In-Reply-To: <20000721233903.A21976@freebie.demon.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > These are 64 bit WWNs. For example the CPQ HSGxx StorageWorks arrays > present a 128 bit extended WWN for each of the LUNs they can present to > the FC-AL/fabric they are connected to. A total of 128 LUNs can be presented > via 2 host port pairs (a pair of ports acts as a failover pair in case one > has redundant array controllers; of each controller one port is part of one > pair). The FC cards only support 64 bit WWNs- these are part of the class 3 service paramaters. The 128 bit WWNs *may* be available- but you have to use VPD info to get at them- all of which is do-able and should be one. > > Serial numbers (IIRC) that are presented by a LUN are all the same: the ser# > of the HSG raid controller. And are therefore quite useless to the problem > at hand. That's why there's a lun qualifier after the serial number. The same thing, btw, applies to 64 bit WWNs- they're for target, not the lun. > So, I think it would be nice if 128 bit WWN could also be handled. Yes, I agree. > A, very desirable IMO, side effect is that once this is done correctly one > can use the information for use in a dual-rail driver. For HA systems having > a dual connection to a RAID box becomes rather common these days. Using > the WWNs it is relatively easy to spot multiple paths to a single LUN/disk. Yes! Yes! Yes! Exacto-mundo! > ... > The problem I see is the fact that I have yet to meet someone who can > correctly transcribe 64 bit numbers, let alone 128bit ones.. :-( But there > is only so much you can do about that problem. Yes- this is indeed a problem. But I would view this as just the need for a tool- possibly Tcl/Tk with X extensions, to allow you to do volume selection which would be responsible for adding things to fstab. But do people have any plus/minus feelings about linking mount with libcam so it can try and translation information? I also feel that it would be better if this were less device class specific, but maybe that waits the full devfs (which I don't expect to see in 5.0). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 21 18:48: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id CE17837B5B2 for ; Fri, 21 Jul 2000 18:48:05 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA78477 for ; Fri, 21 Jul 2000 18:48:05 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Fri, 21 Jul 2000 18:48:05 -0700 (PDT) From: Kris Kennaway To: arch@freebsd.org Subject: Quantifying entropy Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1437619991-964230485=:68809" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1437619991-964230485=:68809 Content-Type: TEXT/PLAIN; charset=US-ASCII I've been playing around with measuring the entropy of sound card microphone inputs when they have no microphone attached (i.e. intrinsic noise in the sound card). I've tested on two systems: my SB16 and a CS423x, and found quite different results: My SB16 in 8bit mode has about 0.06 bits of entropy per sample The CS423x has about 5.8 bits per sample (!). SB16 in 16bit mode recording seems to be broken at the moment. CS423x in 16bit mode has about 8.5 bits per sample. The noise spectra look mostly gaussian (except for the SB16 which gives a weird quantized spectrum of only 5 possible return values and a strongly correlated output pattern ;-, though I've not plotted them, but only inspected the frequency distribution table. I haven't performed any statistical tests for signal correlation beyond calculating the Shannon entropy in the probability distribution. I'd be interested to see results from other people (test program attached) What this seems to suggest is that in the wider picture of gathering entropy, the amount of noise in a given (logical) source is going to be very hardware and system-specific, and trying to assign a fixed weight to it may either grossly overestimate or underestimate the amount of true entropy in the sample. It would seem to make sense then to provide a way for a userland tool to attach to a specific entropy provider in the kernel, which would be fed the raw measurements from the source for analysis over some representative sample period. Using some tool or set of tools the entropy of the signal can be calculated and then the weighting of the source tuned in the kernel, using sysctl or something (although making it persistent might be a problem). We can still try and provide a set of resonable defaults by gathering and averaging measurements from a lot of different systems, but an interested administrator can tune things more efficiently for his local system. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe --0-1437619991-964230485=:68809 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="entropy.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="entropy.c" I2luY2x1ZGUgPHN5cy90aW1lLmg+DQojaW5jbHVkZSA8c3lzL3R5cGVzLmg+ DQojaW5jbHVkZSA8c3lzL2lvY3RsLmg+DQojaW5jbHVkZSA8c3lzL3NvdW5k Y2FyZC5oPg0KDQojaW5jbHVkZSA8ZXJyLmg+DQojaW5jbHVkZSA8ZmNudGwu aD4NCiNpbmNsdWRlIDxtYXRoLmg+DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNp bmNsdWRlIDxzdHJpbmcuaD4NCiNpbmNsdWRlIDx1bmlzdGQuaD4NCg0KI2Rl ZmluZSBERVYgIi9kZXYvZHNwIg0KDQppbnQgbWFpbigpIHsNCiAgaW50IGks IGosIGZkOw0KICB1aW50MTZfdCBidWZbODE5Ml07IA0KICB1bnNpZ25lZCBs b25nIG49MCwgbT0wOw0KICB1aW50MzJfdCBwWzY1NTM2XTsNCiAgZmxvYXQg cywgcHIsIGxuMjsNCiAgc3RydWN0IHRpbWV2YWwgdHYxLCB0djI7DQogIHN0 cnVjdCBfc25kX2NhcGFiaWxpdGllcyBzbmRjYXA7DQogIHN0cnVjdCBfc25k X2NoYW5fcGFyYW0gc25kcGFyOw0KICANCiAgbG4yID0gbG9nZigyKTsNCg0K ICBpZiAoKGZkID0gb3BlbihERVYsIE9fUkRXUnxPX05PTkJMT0NLKSkgPT0g TlVMTCkNCiAgICBlcnIoMSwgIm9wZW4iKTsNCiAgDQogIGlmIChpb2N0bChm ZCwgQUlPR0NBUCwgJnNuZGNhcCkgPT0gLTEpDQogICAgZXJyKDEsICJBSU9H Q0FQIik7DQoNCiAgcHJpbnRmKCJtaW49JWQgbWF4PSVkXG4iLCBzbmRjYXAu cmF0ZV9taW4sIHNuZGNhcC5yYXRlX21heCk7DQoNCiAgc25kcGFyLnBsYXlf cmF0ZT1zbmRjYXAucmF0ZV9tYXg7DQogIHNuZHBhci5yZWNfcmF0ZT1zbmRj YXAucmF0ZV9tYXg7DQogIHNuZHBhci5wbGF5X2Zvcm1hdD1BRk1UX1MxNl9M RTsNCiAgc25kcGFyLnJlY19mb3JtYXQ9QUZNVF9TMTZfTEU7DQoNCiAgaWYg KChpb2N0bChmZCwgQUlPU0ZNVCwgJnNuZHBhcikpID09IC0xKQ0KICAgIGVy cigxLCAiQUlPU0ZNVCIpOw0KICANCiAgYnplcm8ocCwgc2l6ZW9mKHApKTsN CiAgDQogIGdldHRpbWVvZmRheSgmdHYxLCBOVUxMKTsNCiAgDQogIHdoaWxl KDEpIHsNCiAgICBpID0gcmVhZChmZCwgJmJ1Ziwgc2l6ZW9mKGJ1ZikpOw0K ICAgIGZvcihqPTA7ajwoaS8yKTtqKyspIHsNCiAgICAgIHBbYnVmW2pdXSsr Ow0KICAgICAgbisrOw0KICAgIH0NCiAgICBtKys7DQogICAgaWYgKG0gJSA1 MDAwMDAgPT0gMCkgew0KICAgICAgcz0wLjsNCiAgICAgIGdldHRpbWVvZmRh eSgmdHYyLCBOVUxMKTsNCiAgICAgIGZvcihpPTA7aTw2NTUzNjtpKyspIHsN CiNpZmRlZiBERUJVRw0KCWlmIChwW2ldKSBwcmludGYoIiVkPSVkICIsaSxw W2ldKTsNCiNlbmRpZg0KCXByID0gKChmbG9hdClwW2ldLyhmbG9hdCluKTsN CglpZiAocHIgIT0gMC4pIHsNCgkgIHMgLT0gcHIgKiBsb2dmKHByKS8gbG4y Ow0KCX0NCiAgICAgIH0NCiAgICAgIHByaW50ZigibiA9ICVkLCByYXRlID0g JWYsIHMgPSAlZlxuIiwgbiwgKGZsb2F0KShuKS8odHYyLnR2X3NlYyAtIHR2 MS50dl9zZWMpLCBzKTsNCiAgICB9DQogIH0NCn0NCg== --0-1437619991-964230485=:68809-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jul 21 22:40: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 82ED137B576; Fri, 21 Jul 2000 22:39:30 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id BAA61106; Sat, 22 Jul 2000 01:39:29 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200007220539.BAA61106@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Kris Kennaway Cc: arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Quantifying entropy References: In-reply-to: Your message of "Fri, 21 Jul 2000 18:48:05 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Jul 2000 01:39:29 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Another source of noise could be via the RF tuner in a video capture baord. You could get plenty 'o noise on both the audio output as well as the noisy video fields when tuned to an unused channel. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 7:14:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0B9EA37C34D; Sat, 22 Jul 2000 07:14:37 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 22 Jul 2000 10:14:35 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: "Louis A. Mamakos" Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: Quantifying entropy In-Reply-To: <200007220539.BAA61106@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 22 Jul 2000, Louis A. Mamakos wrote: > > Another source of noise could be via the RF tuner in a video capture > baord. You could get plenty 'o noise on both the audio output as > well as the noisy video fields when tuned to an unused channel. Remember that this approach is easily subverted. An attacker can compromise your entropy by detecting what frequency you are tuned to and attack that frequency with predictable data. A protection to this would be a good implementation of a spread-spectrum and spectrum-hopping RF tuner, but then you're relying on its PRNG for the data, really, and if it were that good you'd want to use it anyway ;) > louie -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 7:27:16 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 4C78837B97B; Sat, 22 Jul 2000 07:27:12 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id QAA00347; Sat, 22 Jul 2000 16:27:04 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Fundakowski Feldman Cc: "Louis A. Mamakos" , Kris Kennaway , arch@FreeBSD.ORG Subject: Re: Quantifying entropy In-reply-to: Your message of "Sat, 22 Jul 2000 10:14:35 EDT." Date: Sat, 22 Jul 2000 16:27:04 +0200 Message-ID: <345.964276024@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Brian F undakowski Feldman writes: >> >> Another source of noise could be via the RF tuner in a video capture >> baord. You could get plenty 'o noise on both the audio output as >> well as the noisy video fields when tuned to an unused channel. > >Remember that this approach is easily subverted. An attacker can >compromise your entropy by detecting what frequency you are tuned to >and attack that frequency with predictable data. A protection to >this would be a good implementation of a spread-spectrum and >spectrum-hopping RF tuner, but then you're relying on its PRNG for >the data, really, and if it were that good you'd want to use it anyway ;) Not to be attacking Brian in particular, but I am getting pretty damn tired of seing any suggestion put forth in this thread getting shot down from black helicopters by Elvis. Yes, of course I could simulate the local quardrant of the galaxy at a quantummechanical level and predict everything, but is it really realistic ? The point here is not about making random bits which cannot possibly be compromised. People who need that know how to get that. This is about making the best *realisticly possible* random numbers for FreeBSD (note the emphasis). I can only applaud and congratulate MarkM on what he has managed to do so far in the face of an infinite army of bikeshed building arm-chair generals. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 7:32:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 8B80637C241; Sat, 22 Jul 2000 07:32:25 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id KAA66024; Sat, 22 Jul 2000 10:32:24 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200007221432.KAA66024@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Fundakowski Feldman Cc: Kris Kennaway , arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Quantifying entropy References: In-reply-to: Your message of "Sat, 22 Jul 2000 10:14:35 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Jul 2000 10:32:24 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 22 Jul 2000, Louis A. Mamakos wrote: > > > > > Another source of noise could be via the RF tuner in a video capture > > baord. You could get plenty 'o noise on both the audio output as > > well as the noisy video fields when tuned to an unused channel. > > Remember that this approach is easily subverted. An attacker can > compromise your entropy by detecting what frequency you are tuned to > and attack that frequency with predictable data. A protection to > this would be a good implementation of a spread-spectrum and > spectrum-hopping RF tuner, but then you're relying on its PRNG for > the data, really, and if it were that good you'd want to use it anyway ;) Easily subverted by whom? Since this isn't an FM detector, there is no "capture" effect, and there are a considerable number of noise sources to be overcome by an attacker with a transmitter trying to saturate an AM (well, vestigal sideband) detector. And that's assuming if the tuner actually been connected to an antenna. Further, even if it was, it's unclear that I'd characterize this as "easily subverted"; assuming an attacker was generating NTSC video on a channel, and it had good sync, and it was a fully saturated black luminence signal, there's still going to be noise in the A/D converter on the video capture card. And that's assuming he in fact can detect the LO of the tuner, buried inside the case of the computer along with a bunch of other oscillators, and that you haven't just tuned to a random frequency before capturing a frame of snow. I would think that a broad-band jammer covering all the broadcast (or cable for that matter) spectrum would be noticeable, especially one as powerful as you postulate. I think we're overestimating the extent of the threat. Hell, an attacker could fire a particle beam at phk's geiger counter and comprise it as well. Or break into the facility and just steal the physical assets, rather than mucking about with all this complicated stuff. If I was seriously concerned about these sorts of attacks, then I'd spend a few thousand dollars to address them. As it is, I don't seem the problem with cranking in some perhaps "suspect" entropy data when the alternative is doing nothing. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 7:36:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 949F137C232; Sat, 22 Jul 2000 07:36:24 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id QAA00408; Sat, 22 Jul 2000 16:36:14 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Louis A. Mamakos" Cc: Brian Fundakowski Feldman , Kris Kennaway , arch@FreeBSD.ORG Subject: Re: Quantifying entropy In-reply-to: Your message of "Sat, 22 Jul 2000 10:32:24 EDT." <200007221432.KAA66024@whizzo.transsys.com> Date: Sat, 22 Jul 2000 16:36:14 +0200 Message-ID: <406.964276574@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200007221432.KAA66024@whizzo.transsys.com>, "Louis A. Mamakos" writ es: >I think we're overestimating the extent of the threat. Hell, an attacker >could fire a particle beam at phk's geiger counter and comprise it as well. Actually, he would just give me more random bits that way :-) The way to use a geiger is to time three events: e1 e2 e3 |-T1---|---T2--| if T1 > T2 bit == 0 else if T1 < T2 bit == 1 else try_again; And invert every other bit to remove any systematic bias. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 9:56: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 49B6237B6C9 for ; Sat, 22 Jul 2000 09:55:58 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id JAA28698 for ; Sat, 22 Jul 2000 09:55:57 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA50628; Sat, 22 Jul 2000 09:55:57 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Sat, 22 Jul 2000 09:55:57 -0700 (PDT) Message-Id: <200007221655.JAA50628@vashon.polstra.com> To: arch@freebsd.org Reply-To: arch@freebsd.org Subject: Re: Quantifying entropy In-Reply-To: <345.964276024@critter.freebsd.dk> References: <345.964276024@critter.freebsd.dk> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <345.964276024@critter.freebsd.dk>, Poul-Henning Kamp wrote: > > Not to be attacking Brian in particular, but I am getting pretty > damn tired of seing any suggestion put forth in this thread getting > shot down from black helicopters by Elvis. Me too! This is completely unproductive. I'm getting close to the point of putting "entropy" and "random" into my kill file. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 10: 2:28 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 48DC937BA46; Sat, 22 Jul 2000 10:01:58 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sat, 22 Jul 2000 13:01:43 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: "Louis A. Mamakos" Cc: Kris Kennaway , arch@FreeBSD.ORG Subject: Re: Quantifying entropy In-Reply-To: <200007221432.KAA66024@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ trimmed unwieldly-growing quotes ] I didn't mean that it shouldn't be used for a source of entropy! I meant that if it's used, it should be clocked, tuned by a separate PRNG (a crappy one would work :), and only a single read should be done at the frequency. I want it to be able to be enabled (sysctl or something), sure, but I don't want support for adding entropy by doing dd if=/dev/bktr0 of=/dev/random. I don't think it's a bad idea to take some entropy from the card, but personally, I don't want to see it being made easy for people to think they're adding entropy (^_^) I want to hear more about the proposal about the method you want to use exactly to gather entropy from the card. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 10:16: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 65A7F37BA64; Sat, 22 Jul 2000 10:16:00 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id NAA66718; Sat, 22 Jul 2000 13:15:59 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200007221715.NAA66718@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Fundakowski Feldman Cc: Kris Kennaway , arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Quantifying entropy References: In-reply-to: Your message of "Sat, 22 Jul 2000 13:01:43 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Jul 2000 13:15:59 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tell you what, if anyone has some software which can be used to evaluate the "randomness" of a bucket of bits, I'll run some experiments. I'm convinced that even on a static, snow-free picture you will extract some useful randomness just due to the noise of the tuner and A/D converter used in the video detection process. Using a completely unoccupied channel with no signal present will be that much better. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 10:27:41 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id F290637BC20; Sat, 22 Jul 2000 10:27:30 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id TAA00895; Sat, 22 Jul 2000 19:27:18 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Louis A. Mamakos" Cc: Brian Fundakowski Feldman , Kris Kennaway , arch@FreeBSD.ORG Subject: Re: Quantifying entropy In-reply-to: Your message of "Sat, 22 Jul 2000 13:15:59 EDT." <200007221715.NAA66718@whizzo.transsys.com> Date: Sat, 22 Jul 2000 19:27:17 +0200 Message-ID: <893.964286837@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200007221715.NAA66718@whizzo.transsys.com>, "Louis A. Mamakos" writ es: > >Tell you what, if anyone has some software which can be used to >evaluate the "randomness" of a bucket of bits, I'll run some experiments. >I'm convinced that even on a static, snow-free picture you will extract >some useful randomness just due to the noise of the tuner and A/D converter >used in the video detection process. Using a completely unoccupied channel >with no signal present will be that much better. http://stat.fsu.edu/~geo/diehard.html -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 14:31:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from zippy.osd.bsdi.com (zippy.osd.bsdi.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 273C837B8BF for ; Sat, 22 Jul 2000 14:31:33 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA12078 for ; Sat, 22 Jul 2000 14:31:27 -0700 (PDT) (envelope-from jkh@zippy.osd.bsdi.com) To: arch@FreeBSD.ORG Subject: Re: Quantifying entropy In-reply-to: Your message of "Sat, 22 Jul 2000 09:55:57 PDT." <200007221655.JAA50628@vashon.polstra.com> Date: Sat, 22 Jul 2000 14:31:27 -0700 Message-ID: <12075.964301487@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Me too! This is completely unproductive. I'm getting close to the > point of putting "entropy" and "random" into my kill file. The only way I can see this discussion being useful is if we come up with some way to subscribe one's /dev/random to one of our mailing lists. That would be a fine source of entropy, would it not? :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 18:20:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 25B0E37B562; Sat, 22 Jul 2000 18:20:14 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA45810; Sat, 22 Jul 2000 18:20:14 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sat, 22 Jul 2000 18:20:13 -0700 (PDT) From: Kris Kennaway To: Poul-Henning Kamp Cc: Brian Fundakowski Feldman , "Louis A. Mamakos" , arch@FreeBSD.ORG Subject: Re: Quantifying entropy In-Reply-To: <345.964276024@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 22 Jul 2000, Poul-Henning Kamp wrote: > Not to be attacking Brian in particular, but I am getting pretty > damn tired of seing any suggestion put forth in this thread getting > shot down from black helicopters by Elvis. It's sensible to consider possible attacks against the entropy source, but it's also dependant on the threat model you choose - for most people, radio signal-jamming by men in black suits is probably not on their threat radar :-) Really, the question to ask is "can this source be used to gather bits which are not under the control of an attacker with modest resources, or visible to him?" The answer for most things is "yes, to some extent" at which point further speculation becomes useless until someone actually implements the measurement hooks and tests them for quality. For example, the "safest" use for the radio receiver may be from the intrinsic sampling noise. Which hooks should be used on a system and what weight they should be given is a matter for local policy and customization and should be exposed to the administrator (with "reasonable" system defaults). > Yes, of course I could simulate the local quardrant of the galaxy > at a quantummechanical level and predict everything, but is it > really realistic ? Actually mainstream physics says this is not even possible, so you can rest easy on that front :-) > I can only applaud and congratulate MarkM on what he has managed > to do so far in the face of an infinite army of bikeshed building > arm-chair generals. I havent seen anyone attacking Mark for what he has done. He was attacked for his methods in introducing it to FreeBSD, and there are implementation and algorithmic details yet to be resolved to everyone's satisfcation, but I think everyone agrees that it's a fundamentally good and useful thing. To paraphrase a saying: when the only discussion metaphor you have is a bikeshed, all the world looks green :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 19:52: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id 43DB337B705; Sat, 22 Jul 2000 19:51:56 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id ACCBC52; Sat, 22 Jul 2000 22:51:53 -0400 (AST) Message-ID: <397A5DC9.91DAAD8C@vangelderen.org> Date: Sat, 22 Jul 2000 22:51:53 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: arch@freebsd.org Subject: Re: Quantifying entropy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > I've been playing around with measuring the entropy of sound card > microphone inputs when they have no microphone attached (i.e. intrinsic > noise in the sound card). I've tested on two systems: my SB16 and a > CS423x, and found quite different results: > > My SB16 in 8bit mode has about 0.06 bits of entropy per sample > The CS423x has about 5.8 bits per sample (!). > > SB16 in 16bit mode recording seems to be broken at the moment. > CS423x in 16bit mode has about 8.5 bits per sample. Kewl! > The noise spectra look mostly gaussian (except for the SB16 which gives a > weird quantized spectrum of only 5 possible return values and a strongly > correlated output pattern ;-, though I've not plotted them, but only > inspected the frequency distribution table. I haven't performed any > statistical tests for signal correlation beyond calculating the Shannon > entropy in the probability distribution. I'd be interested to see results > from other people (test program attached) Could you make a couple of megabytes of you raw samples available? I don't have a soundcard at hand but I do have the FIPS-140 tests and a bunch of others. > What this seems to suggest is that in the wider picture of gathering > entropy, the amount of noise in a given (logical) source is going to be > very hardware and system-specific, and trying to assign a fixed weight to > it may either grossly overestimate or underestimate the amount of true > entropy in the sample. The Yarrow authors proposed various methods of dynamically estimating the entropy. One of those was to simply feed the data trough gzip and see how much it compresses. Halve the number of compressed bits and would have a pretty conservative estimate. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_ \_| \ _|/' \/ (_)>(_) (_) (_) (_) (_)' _\o_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 19:52: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from home.rusher.com (jrusher.dsl.speakeasy.net [216.254.15.51]) by hub.freebsd.org (Postfix) with ESMTP id 7E8FA37B6D6 for ; Sat, 22 Jul 2000 19:51:51 -0700 (PDT) (envelope-from jar@integratus.com) Received: from integratus.com (localhost [127.0.0.1]) by home.rusher.com (8.9.3/8.9.3) with ESMTP id TAA00266; Sat, 22 Jul 2000 19:51:37 -0700 (PDT) (envelope-from jar@integratus.com) Message-ID: <397A5DB9.846B905@integratus.com> Date: Sat, 22 Jul 2000 19:51:37 -0700 From: Jack Rusher Organization: Integratus, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com, freebsd-arch@freebsd.org Subject: Re: SANs, disks, & devfs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > As a taste test, how would modifying mount to understand WWNs && serial > numbers and do the appropriate translation to get the current 'da' instance > number feel for people? This way, you might have something like > > fcwwn@0x21000020370752ba,0 / ufs rw 1 1 > scsidsn@"LAE84063",0 /space ufs rw 0 0 > > Thoughts? If something is going to be modified to understand this, I would like it to be vinum. Most of my uses for FCAL attached storage involve some form of volume management. This approach does, of course, bring up the notion of a /devfs directory that contains the real disk information and a set of links in /dev (or /dev/dsk) that map the common names to the right devices. One of the big wins of using links to do this is that moving the disks around won't change where they appear in the /dev/da[0..N] namespace. Solaris style boot -r, anyone? -- Jack Rusher, Senior Software Engineer | mailto:jar@integratus.com Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 20:18:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 77CBE37B521; Sat, 22 Jul 2000 20:18:38 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id UAA55588; Sat, 22 Jul 2000 20:18:38 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sat, 22 Jul 2000 20:18:37 -0700 (PDT) From: Kris Kennaway To: "Jeroen C. van Gelderen" Cc: arch@freebsd.org Subject: Re: Quantifying entropy In-Reply-To: <397A5DC9.91DAAD8C@vangelderen.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote: > Could you make a couple of megabytes of you raw samples > available? I don't have a soundcard at hand but I do > have the FIPS-140 tests and a bunch of others. Sure, they're at physics.usc.edu/~kennaway/soundnoise.bz2 (just over 10M worth) Some interesting numbers: The shannon entropy of this sample as a pure probability distribution is 8.50 bits/sample (they're 16-bit signed values). Compressing with gzip -9 and comparing the file sizes gives an entropy estimate of 10.4 bits/sample. Compressing with bzip2 -9 gives an estimate of 7.90 bits/sample, suggesting there is indeed some time-correlation in the signal noise. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jul 22 21: 9:49 2000 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 52C5437B8CF; Sat, 22 Jul 2000 21:09:42 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id AAA76739; Sun, 23 Jul 2000 00:08:12 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200007230408.AAA76739@whizzo.transsys.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Jeroen C. van Gelderen" Cc: Kris Kennaway , arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Quantifying entropy References: <397A5DC9.91DAAD8C@vangelderen.org> In-reply-to: Your message of "Sat, 22 Jul 2000 22:51:53 EDT." <397A5DC9.91DAAD8C@vangelderen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Jul 2000 00:08:12 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Could you make a couple of megabytes of you raw samples > available? I don't have a soundcard at hand but I do > have the FIPS-140 tests and a bunch of others. I've got some raw data sampled from my Bt848 video capture card that I'm interested in having you evaluate. You can look at http://www.transsys.com/louie/entropy and see a bunch of files: -rw-r--r-- 1 louie wheel 96384000 Jul 22 23:44 ch16.bits -rw-r--r-- 1 louie wheel 2048000 Jul 22 23:45 ch16.bits.subset -rw-r--r-- 1 louie wheel 990841 Jul 22 23:45 ch16.bits.subset.gz -rw-r--r-- 1 louie wheel 73743 Jul 22 23:40 ch16.ppm -rw-r--r-- 1 louie wheel 96192000 Jul 22 20:14 ch4.bits -rw-r--r-- 1 louie wheel 2048000 Jul 22 23:21 ch4.bits.subset -rw-r--r-- 1 louie wheel 1604791 Jul 22 23:27 ch4.bits.subset.gz -rw-r--r-- 1 louie wheel 192015 Jul 22 23:19 ch4.ppm -rw-r--r-- 1 louie wheel 96384000 Jul 22 22:01 ch47.bits -rw-r--r-- 1 louie wheel 2048000 Jul 22 23:21 ch47.bits.subset -rw-r--r-- 1 louie wheel 1767718 Jul 22 23:28 ch47.bits.subset.gz -rw-r--r-- 1 louie wheel 192015 Jul 22 23:18 ch47.ppm -rw-r--r-- 1 louie wheel 135348224 Jul 22 21:50 ch6.bits -rw-r--r-- 1 louie wheel 2048000 Jul 22 23:21 ch6.bits.subset -rw-r--r-- 1 louie wheel 1761347 Jul 22 23:28 ch6.bits.subset.gz -rw-r--r-- 1 louie wheel 192015 Jul 22 23:19 ch6.ppm There are 4 files associated with 4 different RF video sources: channel 4 - live, broadcast TV video from the local NBC affiliate. I don't know what programming was active at the time, probably some commercial :-) channel 6 - unused channel, but shows some adjacent channel interference from an in-use channel (both 5 and 7 are in use). channel 47 - unused channel, but mostly just snow on the screen with no obvious adjacent channel interference. channel 16 - live, locally generated video. This is a static display generated by a FreeBSD box connected to an VGA/baseband composite video converter, driving an RF modulator. It's an application that runs on my FreeBSD-based home automation controller, and during this run, probably only the clock is changing once per second, with the remainder of the display unchanged. (The sample image has been edited obscure phone numbers.) There are 4 files for each source: - foo.bits - the raw data captured from the Bt848 card. This was was gathered using a script something like this: for f in $(jot 450); do ./grab -width 320 -height 200 -channel 47 | tail +5 >> ch47.bits done The "./grab" program captures a video frame of the specified size and from the broadcast channel specified, and writes it to the standard output. The tail command skips over the PPM header, and the remaining image data is appended to a file. This is repeated a bunch of times to get the desired quantity of data. - The foo.subset files are simply the first two megabytes of the full-length files. - The foo.subset.gz file are run through gzip to see how compressable the data is. Interestingly, gzip isn't able to compress most of the files very much; though the mostly static video display frame is the most compressable at just over half; the ch4 data (of actual video) is somewhat more compressable than the other data which is mostly noise. - The foo.ppm files are just a representative frame of captured video, with the PPM header still intact. There is no signifcance to the different sizes of files; this is an artifact of how many frames I captured as I was hacking with the script to do it. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message