Date: Mon, 21 Aug 2000 09:27:02 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Warner Losh <imp@village.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/bktr bktr_os.c src/sys/dev/md md.c src/sys/fs/devfs devfs.h devfs_devs.c devfs_vfsops.c devfs_vnops.c src/sys/i386/conf GENERIC src/sys/i4b/driver i4b_ctl.c i4b_rbch.c i4b_tel.c i4b_trace.c ... Message-ID: <91478.966842822@critter> In-Reply-To: Your message of "Sun, 20 Aug 2000 20:14:36 MDT." <200008210214.UAA35416@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200008210214.UAA35416@harmony.village.org>, Warner Losh writes: >In message <200008202134.OAA42108@freefall.freebsd.org> Poul-Henning Kamp writes: >: Add devfs cloning to: >: disk minilayer (ie: ad(4), sd(4), cd(4) etc etc) > >Why bother with sd? Shouldn't that be da? > >: md(4), tun(4), bpf(4), fd(4) >... >: Add commented out DEVFS to GENERIC > >Question: Is this DEVFS interrupt context safe? The old DEVFS didn't >deal well with devices arriving in an interrupt context, which CAM >does. This one is interrupt context safe. The assignment of the devfs inode number is a cheap atomic instruction which is the only thing done in interrupt context. The rest of the action happens in the context of the process accesing devs. This also means that if you have N devfs's which are rarely accessed the effort to keep their state up to date is optimized away -- 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 cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91478.966842822>