From owner-cvs-sys Sun Oct 22 00:15:04 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA27696 for cvs-sys-outgoing; Sun, 22 Oct 1995 00:15:04 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA27680 ; Sun, 22 Oct 1995 00:14:50 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA23370; Sun, 22 Oct 1995 16:41:03 +1000 Date: Sun, 22 Oct 1995 16:41:03 +1000 From: Bruce Evans Message-Id: <199510220641.QAA23370@godzilla.zeta.org.au> To: jkh@time.cdrom.com, pst@shockwave.com Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-cvs-sys@freebsd.org Precedence: bulk >Just FYI, it's never been mine. I routinely use structure >initializers that only gcc grocks, and have even been known to do the >occasional: > { > char foo[n]; > .. > } >To do the job of alloca.. Not that I use the latter construct very >often - I generally just use alloca directly, but the point is that if /usr/src/usr.sbin/config/main.c:120: warning: ANSI C forbids variable-size array `tmp' It's a nice feature, but it probably shouldn't be used without ifdefs in a bootstrapping utility, and using ifdefs negates the advantage of having it (you have to write ugly portable code _and_ ugly ifdefs _and_ code using the feature instead of just ugly portable code). Bruce From owner-cvs-sys Sun Oct 22 02:32:58 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01117 for cvs-sys-outgoing; Sun, 22 Oct 1995 02:32:58 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01107 ; Sun, 22 Oct 1995 02:32:50 -0700 Date: Sun, 22 Oct 1995 02:32:50 -0700 From: David Greenman Message-Id: <199510220932.CAA01107@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/ufs/ufs ufs_lookup.c ufs_vnops.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/22 02:32:49 Modified: sys/isofs/cd9660 cd9660_lookup.c sys/kern vfs_lookup.c vfs_syscalls.c vfs_vnops.c sys/msdosfs msdosfs_vnops.c sys/nfs nfs_vnops.c sys/ufs/ufs ufs_lookup.c ufs_vnops.c Log: Moved the filesystem read-only check out of the syscalls and into the filesystem layer, as was done in lite-2. Merged in some other cosmetic changes while I was at it. Rewrote most of msdosfs_access() to be more like ufs_access() and to include the FS read-only check. Obtained from: partially from 4.4BSD-lite2 From owner-cvs-sys Sun Oct 22 02:38:01 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01321 for cvs-sys-outgoing; Sun, 22 Oct 1995 02:38:01 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01310 ; Sun, 22 Oct 1995 02:37:49 -0700 Date: Sun, 22 Oct 1995 02:37:49 -0700 From: David Greenman Message-Id: <199510220937.CAA01310@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/nfs nfs_vnops.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/22 02:37:48 Modified: sys/nfs nfs_vnops.c Log: Fix order problem: unbusy pages before releasing the buffer. Submitted by: John Dyson From owner-cvs-sys Sun Oct 22 08:07:55 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10494 for cvs-sys-outgoing; Sun, 22 Oct 1995 08:07:55 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10483 ; Sun, 22 Oct 1995 08:07:45 -0700 Date: Sun, 22 Oct 1995 08:07:45 -0700 From: Bruce Evans Message-Id: <199510221507.IAA10483@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/isa isa.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk bde 95/10/22 08:07:44 Modified: sys/i386/isa isa.c Log: Only allow `sensitive' devices for displays in find_display(). This is a quick fix for syscons deciding not to become the console because it thinks another tty device has priority. From owner-cvs-sys Sun Oct 22 08:38:16 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11497 for cvs-sys-outgoing; Sun, 22 Oct 1995 08:38:16 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA11485 ; Sun, 22 Oct 1995 08:38:10 -0700 Date: Sun, 22 Oct 1995 08:38:10 -0700 From: Bruce Evans Message-Id: <199510221538.IAA11485@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/isa sio.c cy.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk bde 95/10/22 08:38:09 Modified: sys/i386/isa sio.c cy.c Log: sio.c: Fix the tests for being a console by reverting to the ones that were used before the the RB_SERIAL changes. RB_SERIAL only needs to be tested in one place. The initialization of comconsole was wrong before the RB_SERIAL changes for the COMCONSOLE case. This may have been the cause of the unnecessary changes. Start eliminating #includes of . This header is supposed to be included from although it should be completely machine-independent and included from . Remove a wrong XXX comment. `comconsole' is used to test for being a console and even the tests for deciding the default termios state are necessary (the semi-reentrant i/o routines don't handle ordinary device i/o). cy.c: Sync with sio.c. The console tests are present but always fail. From owner-cvs-sys Sun Oct 22 12:08:03 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA03470 for cvs-sys-outgoing; Sun, 22 Oct 1995 12:08:03 -0700 Received: (from phk@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA03455 ; Sun, 22 Oct 1995 12:08:00 -0700 Date: Sun, 22 Oct 1995 12:08:00 -0700 From: Poul-Henning Kamp Message-Id: <199510221908.MAA03455@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/netinet if_ether.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk phk 95/10/22 12:07:59 Modified: sys/netinet if_ether.c Log: Remove the last trace of arptnew() From owner-cvs-sys Sun Oct 22 16:14:55 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11381 for cvs-sys-outgoing; Sun, 22 Oct 1995 16:14:55 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA11371 ; Sun, 22 Oct 1995 16:14:45 -0700 Date: Sun, 22 Oct 1995 16:14:45 -0700 From: David Greenman Message-Id: <199510222314.QAA11371@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/isa wcd.c wd.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/22 16:14:43 Branch: sys/i386/isa RELENG_2_1_0 Modified: sys/i386/isa wcd.c wd.c Log: Walk on egg shells by bringing in pieces of Serge's recent fixes. I've tried to bring in just the most important fixes and leave out the controversial "open reference counting" changes that appear to be mostly wrong. From owner-cvs-sys Sun Oct 22 17:47:14 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13333 for cvs-sys-outgoing; Sun, 22 Oct 1995 17:47:14 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13324 ; Sun, 22 Oct 1995 17:47:11 -0700 Date: Sun, 22 Oct 1995 17:47:11 -0700 From: David Greenman Message-Id: <199510230047.RAA13324@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/i386 pmap.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/22 17:47:11 Modified: sys/i386/i386 pmap.c Log: More improvements to the logic for modify-bit checking. Removed pmap_prefault() code as we don't plan to use it at this point in time. Submitted by: John Dyson From owner-cvs-sys Sun Oct 22 19:23:57 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA16851 for cvs-sys-outgoing; Sun, 22 Oct 1995 19:23:57 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA16835 ; Sun, 22 Oct 1995 19:23:33 -0700 Date: Sun, 22 Oct 1995 19:23:33 -0700 From: John Dyson Message-Id: <199510230223.TAA16835@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/vm vnode_pager.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk dyson 95/10/22 19:23:31 Modified: sys/isofs/cd9660 cd9660_vnops.c sys/miscfs/specfs spec_vnops.c specdev.h sys/ufs/ffs ffs_vnops.c sys/ufs/ufs ufs_readwrite.c sys/vm vnode_pager.c Log: Finalize GETPAGES layering scheme. Move the device GETPAGES interface into specfs code. No need at this point to modify the PUTPAGES stuff except in the layered-type (NULL/UNION) filesystems. From owner-cvs-sys Sun Oct 22 19:31:43 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA17138 for cvs-sys-outgoing; Sun, 22 Oct 1995 19:31:43 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA17122 ; Sun, 22 Oct 1995 19:31:32 -0700 Date: Sun, 22 Oct 1995 19:31:32 -0700 From: David Greenman Message-Id: <199510230231.TAA17122@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/i386 pmap.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/22 19:31:31 Modified: sys/i386/i386 pmap.c Log: Remove PG_W bit setting in some cases where it should not be set. Submitted by: John Dyson From owner-cvs-sys Sun Oct 22 19:56:06 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA18070 for cvs-sys-outgoing; Sun, 22 Oct 1995 19:56:06 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA18061 ; Sun, 22 Oct 1995 19:55:57 -0700 Date: Sun, 22 Oct 1995 19:55:57 -0700 From: John Dyson Message-Id: <199510230255.TAA18061@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/kern vnode_if.src Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk dyson 95/10/22 19:55:56 Modified: sys/kern vnode_if.src Log: Interface change for the VOP_GETPAGES -- missed in previous commits. From owner-cvs-sys Sun Oct 22 20:50:13 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA19782 for cvs-sys-outgoing; Sun, 22 Oct 1995 20:50:13 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA19753 ; Sun, 22 Oct 1995 20:49:52 -0700 Date: Sun, 22 Oct 1995 20:49:52 -0700 From: John Dyson Message-Id: <199510230349.UAA19753@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/vm vm_fault.c vm_mmap.c vm_object.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk dyson 95/10/22 20:49:49 Modified: sys/vm vm_fault.c vm_mmap.c vm_object.c Log: First phase of removing the PG_COPYONWRITE flag, and an architectural cleanup of mapping files. From owner-cvs-sys Sun Oct 22 20:58:36 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA20093 for cvs-sys-outgoing; Sun, 22 Oct 1995 20:58:36 -0700 Received: (from ugen@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA20076 ; Sun, 22 Oct 1995 20:58:13 -0700 Date: Sun, 22 Oct 1995 20:58:13 -0700 From: "Ugen J.S.Antsilevich" Message-Id: <199510230358.UAA20076@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/netinet ip_fw.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk ugen 95/10/22 20:58:10 Modified: sbin/ipfw ipfw.c sys/netinet ip_fw.c Log: Support all the tcpflag options in firewall. Add reading options from file, now ipfw will read commands string after string from file , form of strings same as command line interface. From owner-cvs-sys Sun Oct 22 21:29:21 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA21096 for cvs-sys-outgoing; Sun, 22 Oct 1995 21:29:21 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA21083 ; Sun, 22 Oct 1995 21:29:03 -0700 Date: Sun, 22 Oct 1995 21:29:03 -0700 From: John Dyson Message-Id: <199510230429.VAA21083@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/miscfs/procfs procfs_mem.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk dyson 95/10/22 21:29:01 Modified: sys/miscfs/procfs procfs_mem.c Log: Removal of unnecessary usage of PG_COPYONWRITE. From owner-cvs-sys Sun Oct 22 21:29:52 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA21167 for cvs-sys-outgoing; Sun, 22 Oct 1995 21:29:52 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA21157 ; Sun, 22 Oct 1995 21:29:43 -0700 Date: Sun, 22 Oct 1995 21:29:43 -0700 From: John Dyson Message-Id: <199510230429.VAA21157@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/vm vm_page.h Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk dyson 95/10/22 21:29:42 Modified: sys/vm vm_page.h Log: Remove of now unused PG_COPYONWRITE. From owner-cvs-sys Sun Oct 22 22:35:57 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA22632 for cvs-sys-outgoing; Sun, 22 Oct 1995 22:35:57 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA22623 ; Sun, 22 Oct 1995 22:35:51 -0700 Date: Sun, 22 Oct 1995 22:35:51 -0700 From: John Dyson Message-Id: <199510230535.WAA22623@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/vm vm_glue.c vm_map.c vm_page.c vm_pageout.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk dyson 95/10/22 22:35:50 Modified: sys/vm vm_glue.c vm_map.c vm_page.c vm_pageout.c Log: Get rid of machine-dependent NBPG and replace with PAGE_SIZE. From owner-cvs-sys Sun Oct 22 23:58:21 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA24511 for cvs-sys-outgoing; Sun, 22 Oct 1995 23:58:21 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA24506 ; Sun, 22 Oct 1995 23:58:15 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA16504; Mon, 23 Oct 1995 16:53:05 +1000 Date: Mon, 23 Oct 1995 16:53:05 +1000 From: Bruce Evans Message-Id: <199510230653.QAA16504@godzilla.zeta.org.au> To: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, dyson@freefall.freebsd.org Subject: Re: cvs commit: src/sys/vm vm_glue.c vm_map.c vm_page.c vm_pageout.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk > Modified: sys/vm vm_glue.c vm_map.c vm_page.c vm_pageout.c > Log: > Get rid of machine-dependent NBPG and replace with PAGE_SIZE. What is the relationship between NBPG, PAGE_SIZE and CLBYTES? I Surely there should only be one "machine-independent" "page" size. Bruce From owner-cvs-sys Mon Oct 23 00:06:07 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA24669 for cvs-sys-outgoing; Mon, 23 Oct 1995 00:06:07 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA24663 ; Mon, 23 Oct 1995 00:06:01 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id AAA03274; Mon, 23 Oct 1995 00:05:55 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id AAA00240; Mon, 23 Oct 1995 00:05:33 -0700 Message-Id: <199510230705.AAA00240@corbin.Root.COM> To: Bruce Evans cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/vm vm_glue.c vm_map.c vm_page.c vm_pageout.c In-reply-to: Your message of "Mon, 23 Oct 95 16:53:05 +1000." <199510230653.QAA16504@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 23 Oct 1995 00:05:28 -0700 Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk >> Modified: sys/vm vm_glue.c vm_map.c vm_page.c vm_pageout.c >> Log: >> Get rid of machine-dependent NBPG and replace with PAGE_SIZE. > >What is the relationship between NBPG, PAGE_SIZE and CLBYTES? I >Surely there should only be one "machine-independent" "page" size. NBPG _should_ refer to the hardware page size. PAGE_SIZE should refer to the "software" page size - the size that the independant portion of the VM system uses. CLBYTES is a historical thing that should probably go away. NBPG should probably only be used in the machine-dependant portion of the sources on architectures where NBPG != PAGE_SIZE...in the case of the i386, I personally would prefer that PAGE_SIZE be used everywhere - especially when it's not clear what is 'managed' by the higher VM system layer. -DG From owner-cvs-sys Mon Oct 23 00:26:58 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA25087 for cvs-sys-outgoing; Mon, 23 Oct 1995 00:26:58 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA25081 ; Mon, 23 Oct 1995 00:26:52 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA17572; Mon, 23 Oct 1995 17:23:09 +1000 Date: Mon, 23 Oct 1995 17:23:09 +1000 From: Bruce Evans Message-Id: <199510230723.RAA17572@godzilla.zeta.org.au> To: bde@zeta.org.au, davidg@Root.COM Subject: Re: cvs commit: src/sys/vm vm_glue.c vm_map.c vm_page.c vm_pageout.c Cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk > NBPG _should_ refer to the hardware page size. PAGE_SIZE should refer to >the "software" page size - the size that the independant portion of the VM >system uses. CLBYTES is a historical thing that should probably go away. > NBPG should probably only be used in the machine-dependant portion of the >sources on architectures where NBPG != PAGE_SIZE...in the case of the i386, I >personally would prefer that PAGE_SIZE be used everywhere - especially when >it's not clear what is 'managed' by the higher VM system layer. The VM layer currently seems to manage bothe PAGE_SIZE and NBPG. I think it should manage only higher level pages but don't like the name `PAGE_SIZE' since it's not clear whether that means a hardware page size, a software page size, or the size of a cluster of hardware pages (actually it clearly doesn't mean the cluster size, but it should be thought of as a cluster size in the clustering layer. OTOH, the i386 code should be aware that the software page size is the same as the hardware pages size and have a null clustering layer. I think it should still use NBPG for h/w pages and PAGE_SIZE as little as possible. Bruce From owner-cvs-sys Mon Oct 23 00:43:55 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA25457 for cvs-sys-outgoing; Mon, 23 Oct 1995 00:43:55 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA25452 ; Mon, 23 Oct 1995 00:43:51 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id AAA03356; Mon, 23 Oct 1995 00:43:49 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id AAA01697; Mon, 23 Oct 1995 00:43:23 -0700 Message-Id: <199510230743.AAA01697@corbin.Root.COM> To: Bruce Evans cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/vm vm_glue.c vm_map.c vm_page.c vm_pageout.c In-reply-to: Your message of "Mon, 23 Oct 95 17:23:09 +1000." <199510230723.RAA17572@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 23 Oct 1995 00:43:17 -0700 Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk >> NBPG _should_ refer to the hardware page size. PAGE_SIZE should refer to >>the "software" page size - the size that the independant portion of the VM >>system uses. CLBYTES is a historical thing that should probably go away. >> NBPG should probably only be used in the machine-dependant portion of the >>sources on architectures where NBPG != PAGE_SIZE...in the case of the i386, I >>personally would prefer that PAGE_SIZE be used everywhere - especially when >>it's not clear what is 'managed' by the higher VM system layer. > >The VM layer currently seems to manage bothe PAGE_SIZE and NBPG. I think it >should manage only higher level pages but don't like the name `PAGE_SIZE' >since it's not clear whether that means a hardware page size, a software >page size, or the size of a cluster of hardware pages (actually it clearly >doesn't mean the cluster size, but it should be thought of as a cluster >size in the clustering layer. OTOH, the i386 code should be aware that >the software page size is the same as the hardware pages size and have a >null clustering layer. I think it should still use NBPG for h/w pages and >PAGE_SIZE as little as possible. The VM layer is wrong, and that's partially what John is correcting. I disagree about PAGE_SIZE. The general principle is that to all but the lowest management functions in the pmap layer, the "page size" is a constant and may or may not be made up of a collection of smaller hardware pages. In fact, it may not even be a constant at the hardware level for a given architecture. The hardware page size might be different with different models of a specific CPU type (Sparc, for instance, is 4K on some, 8K on others) or may even be dynamically variable. Thus, "NBPG" becomes quite meaningless and it's generally only useful to speak about the machine-independant constant. I think PAGE_SIZE is quite unambiguous. It's inherited from Mach and I plan for it to stay. :-) -DG From owner-cvs-sys Mon Oct 23 05:05:35 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04610 for cvs-sys-outgoing; Mon, 23 Oct 1995 05:05:35 -0700 Received: (from phk@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04601 ; Mon, 23 Oct 1995 05:05:27 -0700 Date: Mon, 23 Oct 1995 05:05:27 -0700 From: Poul-Henning Kamp Message-Id: <199510231205.FAA04601@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/pccard pcic.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk phk 95/10/23 05:05:26 Modified: sys/pccard pcic.c Log: Fix a missing arg to untimeout. From owner-cvs-sys Mon Oct 23 08:42:23 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10839 for cvs-sys-outgoing; Mon, 23 Oct 1995 08:42:23 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10827 ; Mon, 23 Oct 1995 08:42:15 -0700 Date: Mon, 23 Oct 1995 08:42:15 -0700 From: Bruce Evans Message-Id: <199510231542.IAA10827@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/kern kern_exit.c uipc_syscalls.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk bde 95/10/23 08:42:14 Modified: sys/kern kern_exit.c uipc_syscalls.c Log: Simplify the pseudo-argument removal changes by not optimizing for the !COMPAT_43 case - use a common function even when there is no `old' function. The diffs for this are large because of code motion to restore the function order to what it was before the pseudo-argument changes. Include to get correct args structs and prototypes. The diffs for this are large because the declarations of the args structs were moved to become comments in the function headers. The comments may actually match the automatically generated declarations right now. Add prototypes. From owner-cvs-sys Mon Oct 23 11:51:47 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17730 for cvs-sys-outgoing; Mon, 23 Oct 1995 11:51:47 -0700 Received: (from ache@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17717 ; Mon, 23 Oct 1995 11:51:31 -0700 Date: Mon, 23 Oct 1995 11:51:31 -0700 From: "Andrey A. Chernov" Message-Id: <199510231851.LAA17717@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/conf newvers.sh Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk ache 95/10/23 11:51:30 Modified: sys/conf newvers.sh Log: Reset only one necessary LC_ variable From owner-cvs-sys Mon Oct 23 12:04:32 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18414 for cvs-sys-outgoing; Mon, 23 Oct 1995 12:04:32 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18387 ; Mon, 23 Oct 1995 12:04:19 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11444; Mon, 23 Oct 1995 11:51:33 -0700 From: Terry Lambert Message-Id: <199510231851.LAA11444@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 23 Oct 1995 11:51:33 -0700 (MST) Cc: pst@shockwave.com, swallace@ece.uci.edu, bde@freefall.freebsd.org, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@FreeBSD.ORG In-Reply-To: <26924.814325836@time.cdrom.com> from "Jordan K. Hubbard" at Oct 21, 95 06:37:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 595 Sender: owner-cvs-sys@FreeBSD.ORG Precedence: bulk > I can't imagine porting to (or being interested in) any > platform that did not support gcc, and if it did not then porting gcc > would be my first task anyway! I'm happy you feel this way. I'm using a Motorolla Ultra 603/604 PPC box, PReP compliant, running AIX as a cross-environment. When should I expect your GCC port that supports AIX imports/exports qualifiers that I'm currently using to try out BSD kernel code in the AIX kernel? Thanks, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Mon Oct 23 12:05:56 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18589 for cvs-sys-outgoing; Mon, 23 Oct 1995 12:05:56 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18575 ; Mon, 23 Oct 1995 12:05:51 -0700 Date: Mon, 23 Oct 1995 12:05:51 -0700 From: Bruce Evans Message-Id: <199510231905.MAA18575@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/kern kern_resource.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk bde 95/10/23 12:05:51 Modified: sys/kern kern_resource.c Log: Fix a sign extension bug that was unleashed by the previous change. The total process time was sometimes 2^32 usec too large but that wasn't a problem before because the time was bogusly truncated mod 2^32. From owner-cvs-sys Mon Oct 23 12:07:02 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA18692 for cvs-sys-outgoing; Mon, 23 Oct 1995 12:07:02 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA18662 ; Mon, 23 Oct 1995 12:06:51 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11462; Mon, 23 Oct 1995 11:58:51 -0700 From: Terry Lambert Message-Id: <199510231858.LAA11462@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: swallace@ece.uci.edu (Steven Wallace) Date: Mon, 23 Oct 1995 11:58:50 -0700 (MST) Cc: bde@freefall.freebsd.org, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@FreeBSD.ORG In-Reply-To: <199510212304.QAA06180@newport.ece.uci.edu> from "Steven Wallace" at Oct 21, 95 04:04:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2702 Sender: owner-cvs-sys@FreeBSD.ORG Precedence: bulk > > to get it right. First we need to catch up with 4.4lite2, which uses > > macros to handle struct padding. Then we need to catch up with NetBSD, > I hate that SCARG macro. It makes looking at the code harder to > understand. Perhaps if we did something like: > > read(struct proc *p, void *v, int retval[]) > { > struct read_args /* { > int fd; > char *buf; > u_int nbyte; > } */ *uap = v; > int fd = SCARG(uap, fd); > char *buf = SCARG(uap, buf); > u_int nbyte = SCARG(uap, nbyte); > > ... > } > > That way we don't have SCARG all over the place, and this would > prepare us for your static function idea. Seeing this on -hackers, I'd like to have someone back up and explain "the static function idea", since it seems likely that an alternate approact to the idea might be more fruitful than rewriting the system call interface such that we have to hack tables all over hell for no real gain. > > which passes the args correctly (as void *). Then we need to handle > > varargs functions and struct padding better. I think all the details > > can be hidden in machine-generated functions so that the args structs > > and verbose macros to reference them don't have to appear in the core > > sources. I have macros that divorce K&R and ANSI vararg behaviour from the code itself (I use them for various things myself). Is this what we are trying to accomplish? > > semsys() and shmsys() syscall interfaces are BAD because they > > multiplex several syscalls that have different types of args. > > There was no reason to duplicate this sysv braindamage but now > > we're stuck with it. NetBSD has reimplemented the syscalls properly > > as separate syscalls #220-231. > > I agree. This is yucky! No, this is good -- system calls are a scarce resource and should be consumed conservatively. What's the problem you have with anonymous argument vectors using subfunction codes? > We need a better way to handle these syscall subcodes (as SYSV calls 'em). I guess I don't really understand why these are a problem, unless you are trying to do something silly, like prototype them. > One idea I have is to use special case for the number of parms. > If it is < 0 then special handling should be taken. > case -1: Get code from next parameter. > case -2: Get code from next parameter (quad_t). > case -3: code = (code >> 8) & 0xff; (for ibcs2 xenix emulation) > Then use the function pointer as a pointer to a new sysent, > and do it all over again (making sure no recursion). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Mon Oct 23 12:13:34 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19171 for cvs-sys-outgoing; Mon, 23 Oct 1995 12:13:34 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19154 ; Mon, 23 Oct 1995 12:13:26 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA00464; Mon, 23 Oct 1995 12:12:41 -0700 To: Terry Lambert cc: pst@shockwave.com, swallace@ece.uci.edu, bde@freefall.freebsd.org, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@FreeBSD.ORG Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] In-reply-to: Your message of "Mon, 23 Oct 1995 11:51:33 PDT." <199510231851.LAA11444@phaeton.artisoft.com> Date: Mon, 23 Oct 1995 12:12:41 -0700 Message-ID: <462.814475561@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-cvs-sys@FreeBSD.ORG Precedence: bulk > I'm using a Motorolla Ultra 603/604 PPC box, PReP compliant, running > AIX as a cross-environment. > > When should I expect your GCC port that supports AIX imports/exports > qualifiers that I'm currently using to try out BSD kernel code in the > AIX kernel? Never, but so what? People who use AIX under any circumstances are already so screwed that the compiler is the least of their worries.. :-) I did my time with AIX, and you'll get no sympathy from me. None whatsoever. I'd sooner cross-develop under XENIX! Jordan From owner-cvs-sys Mon Oct 23 12:44:53 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA21002 for cvs-sys-outgoing; Mon, 23 Oct 1995 12:44:53 -0700 Received: (from swallace@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA20959 ; Mon, 23 Oct 1995 12:44:43 -0700 Date: Mon, 23 Oct 1995 12:44:43 -0700 From: Steven Wallace Message-Id: <199510231944.MAA20959@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/kern kern_exit.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk swallace 95/10/23 12:44:42 Modified: sys/kern kern_exit.c Log: Remove COMPAT_IBCS2 option. Ibcs2 emulator no longer depends on owait() or any other hack to wait4(). From owner-cvs-sys Mon Oct 23 12:47:03 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA21340 for cvs-sys-outgoing; Mon, 23 Oct 1995 12:47:03 -0700 Received: (from swallace@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA21317 ; Mon, 23 Oct 1995 12:46:54 -0700 Date: Mon, 23 Oct 1995 12:46:54 -0700 From: Steven Wallace Message-Id: <199510231946.MAA21317@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/ibcs2 ibcs2_misc.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk swallace 95/10/23 12:46:54 Modified: sys/i386/ibcs2 ibcs2_misc.c Log: Add code to properly translate signal returned in status argument of wait4() call for STOPPED and SIGNALED status (exit status identical). From owner-cvs-sys Tue Oct 24 00:47:59 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA23061 for cvs-sys-outgoing; Tue, 24 Oct 1995 00:47:59 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA23019 ; Tue, 24 Oct 1995 00:47:45 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA03491; Tue, 24 Oct 1995 17:39:03 +1000 Date: Tue, 24 Oct 1995 17:39:03 +1000 From: Bruce Evans Message-Id: <199510240739.RAA03491@godzilla.zeta.org.au> To: swallace@ece.uci.edu, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org Sender: owner-cvs-sys@freebsd.org Precedence: bulk >> read(struct proc *p, void *v, int retval[]) >> { >> struct read_args /* { >> int fd; >> char *buf; >> u_int nbyte; >> } */ *uap = v; >> int fd = SCARG(uap, fd); >> char *buf = SCARG(uap, buf); >> u_int nbyte = SCARG(uap, nbyte); >> >> ... >> } >> >> That way we don't have SCARG all over the place, and this would >> prepare us for your static function idea. >Seeing this on -hackers, I'd like to have someone back up and explain >"the static function idea", static inline int read(fd, buf, nbytes) int fd; void *buf; size_t nbytes; ssize_t *retval; { /* * Same as for the current read(), except we don't have to grope * unportably in *uap for the args store the retval in an * incompatible type. */ } /* Machine generated - do not edit. */ int freebsd_syscall_entry_read(p, args, retval) struct proc *p; void *args; int *retval; { int fd; void *buf; size_t nbytes; ssize_t nread; int res; fd = machine_dependent_code_to_convert_fd_for_read(args); buf = machine_dependent_code_to_convert_buf_for_read(args); nbytes = machine_dependent_code_to_convert_nbytes_for_read(args); res = read(fd, buf, nbytes, &nread); machine_dependent_code_to_convert_retval_for_read(args, nread); return (res); } >since it seems likely that an alternate >approact to the idea might be more fruitful than rewriting the system >call interface such that we have to hack tables all over hell for >no real gain. This seems unlikely :-). The main disadvantage of the above is that read() would actually have to be non-static inline so that it can be called from emulators. E.g., foo_ossyscall_entry_read() might have different machine-generated machine-dependent code and it's much better for it to convert from that to (int fd, void *buf, size_t nbytes, ssize_t *retval) and call read() than it is to convert to the machine-dependent freebsd args array and call bsd_syscall_entry_read(). Thus read() would be duplicated at least twice (once inline for fast Freebsd syscalls, once extern for slower foo_os syscalls). All this assumes that the args are in a struct. In general, at the beginning of a syscall, some are in registers and some are in user memory. foo_os_syscall() currently has to copy them to args struct. It might be better to delay the copying to the machine-generated foo_os_syscall_entry_xxx() functions to reduce the amount of copying to the wrong places and to support messy ABI's. >> > which passes the args correctly (as void *). Then we need to handle >> > varargs functions and struct padding better. I think all the details >> > can be hidden in machine-generated functions so that the args structs >> > and verbose macros to reference them don't have to appear in the core >> > sources. >I have macros that divorce K&R and ANSI vararg behaviour from the code >itself (I use them for various things myself). Is this what we are >trying to accomplish? No. Varargs syscalls such as open(), fcntl() and shmsys() mess up the ABI. The args for them have to be copied from different places depending on codes in the early args. syscall() currently assumes that the args are on the stack in user space and copies more args than are necessary and sometimes more than are officially supplied. Varargs for syscall xxx should handled by fetching them from the appropriate place in foo_os_syscall_entry_xxx() and passing them in the normal varargs way to xxx(). > > semsys() and shmsys() syscall interfaces are BAD because they > > multiplex several syscalls that have different types of args. > > There was no reason to duplicate this sysv braindamage but now > > we're stuck with it. NetBSD has reimplemented the syscalls properly > > as separate syscalls #220-231. > > I agree. This is yucky! No, this is good -- system calls are a scarce resource and should be consumed conservatively. What's the problem you have with anonymous argument vectors using subfunction codes? No, this (not syscalls #220-231) is yucky. Multiplexing syscalls takes more code to handle even incorrectly like it does now. Non-multiplexed syscalls take one entry in sysent[] and a function to handle them; multiplexed ones require less entries in sysent[] and an extra function to demultiplex them. The demultiplexing function can be simple and unportable like the current ones or complicated and portable or machine-generated. In general it has to have code like freebsd_syscall_entry_read() for each of the variants. > We need a better way to handle these syscall subcodes (as SYSV calls 'em). I guess I don't really understand why these are a problem, unless you are trying to do something silly, like prototype them. They are a problem because they give more special cases to write code for. Bruce From owner-cvs-sys Tue Oct 24 12:15:52 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA26952 for cvs-sys-outgoing; Tue, 24 Oct 1995 12:15:52 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA26924 ; Tue, 24 Oct 1995 12:15:40 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA13880; Tue, 24 Oct 1995 12:06:38 -0700 From: Terry Lambert Message-Id: <199510241906.MAA13880@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Tue, 24 Oct 1995 12:06:38 -0700 (MST) Cc: swallace@ece.uci.edu, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org In-Reply-To: <199510240739.RAA03491@godzilla.zeta.org.au> from "Bruce Evans" at Oct 24, 95 05:39:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 11822 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > >> That way we don't have SCARG all over the place, and this would > >> prepare us for your static function idea. > > >Seeing this on -hackers, I'd like to have someone back up and explain > >"the static function idea", > > static inline int > read(fd, buf, nbytes) > int fd; > void *buf; > size_t nbytes; > ssize_t *retval; > { > /* > * Same as for the current read(), except we don't have to grope > * unportably in *uap for the args store the retval in an > * incompatible type. > */ > } > > /* Machine generated - do not edit. */ > int > freebsd_syscall_entry_read(p, args, retval) > struct proc *p; > void *args; > int *retval; > { > int fd; > void *buf; > size_t nbytes; > ssize_t nread; > int res; > > fd = machine_dependent_code_to_convert_fd_for_read(args); > buf = machine_dependent_code_to_convert_buf_for_read(args); > nbytes = machine_dependent_code_to_convert_nbytes_for_read(args); > res = read(fd, buf, nbytes, &nread); > machine_dependent_code_to_convert_retval_for_read(args, nread); > return (res); > } > > >since it seems likely that an alternate > >approact to the idea might be more fruitful than rewriting the system > >call interface such that we have to hack tables all over hell for > >no real gain. > > This seems unlikely :-). > > The main disadvantage of the above is that read() would actually have > to be non-static inline so that it can be called from emulators. E.g., > foo_ossyscall_entry_read() might have different machine-generated > machine-dependent code and it's much better for it to convert from that > to (int fd, void *buf, size_t nbytes, ssize_t *retval) and call read() > than it is to convert to the machine-dependent freebsd args array and > call bsd_syscall_entry_read(). Thus read() would be duplicated at least > twice (once inline for fast Freebsd syscalls, once extern for slower > foo_os syscalls). OK. I hate leaving all of the above in for context, but I have to. The disadvantage you cite is false. Internal kernel calls to read do not follow the same rules on inlining. The inlining is to avoid the function call overhead to get to the trap vector. This is, in fact, something that can be done in any case, without a change to the system call interface. The problem seems to be one of understanding trap vector argument decodes. When a system call is made, arguments are pushed on the user stack and then the trap vector is called. There is a necessity to copy the arguments as if they were on the stack down to a kernel space buffer area because of the address space differences. The amount that is copied is determined by an integer count of integers: that is, it is some number 'n' * sizeof(int) bytes that get copied. This is dependent on the arguments pushed on the stack being representable as integer values (we are guaranteed this by the fact that we are calling a non-local function that is not inlined). In any case, the copyin from user to system space in the trap code must occur, since the kernel can not address the process data otherwise. The area where the copyin takes place is a per process work area, and it's a pointer to this that is passed as the argument vector pointer, which assumes packing such that the structure dereference of this data will result in the arguments as referenced from the argument structure. So far, we do not have a use for the change. Now each of the arguments are themselves, potentially, pointers to additional information in call/subcode specific user space structures that must, additionally be copied in (or out to). The potential use for the hack is to get the copyin all out of the way at once with a single verification check, ala Linux system calls. The problem with this idea is that the address space in the user program is then assumed (potentially incorrectly) to be non-discontiguous. While BSD could very well benefit from a single verification, avoiding the mapping issues in copyin/copyout, giving one check instead of two for a reuesd area, the actual benefits of this are fairly small. The biggest benefit would be in the copyinstr area, and there, the algorithm would potentially fail because of indeterminate string length. When we add in the concept of multithreading, it's possible to alter the process address space promiscuously during a long delay operation, such that an area that was viable for a copyout is no longer a viable target. So the benefits are lost. Further, the use of null termination instead of byte count on strings makes the copyinstr() operation extremely onerous. There are only a few locations where the facility is used, and even there, the overhead introduced is largely an issue of bad call interface design. There are two types of strings that get copied in (1) paths and (2) structure arguments (like lkm module but not path names, or NFS server names for NFS mount). In actuality, the structure arguments should be packed into fixed length structure elements and the copyinstr disacarded. The paths can stay, but a seperation of the file system name space from the act of string copying (Linux does this too, though I had to fix a bug in an error path) is a necessary part of the required cleanup for this to happen. Still, we do not benefit from the change. What does it do? What use is the change? In the end, it allows us to alter our argument packing. But the same effect of the optimizer that does that, and destabilizes the structure and stack packing from the historical (and processor efficient) integer norm, also has the effect of (potentiall) using register argument passing at certain optimization levels. This is, of course, crap. It won't work across the trap vector interface for all the registers gcc likes to use. If we are trying for this small an incremental improvement, I suggest spending coding time on getting callee pop working within the kernel code. It would be a much higher gain for less effort. > All this assumes that the args are in a struct. In general, at the > beginning of a syscall, some are in registers and some are in user memory. > foo_os_syscall() currently has to copy them to args struct. It might > be better to delay the copying to the machine-generated > foo_os_syscall_entry_xxx() functions to reduce the amount of copying > to the wrong places and to support messy ABI's. The copying is, in all cases, to the stack, by way of "push". The use of registers for calling in a system call interface is bogus. Removing the function call overhead by inlining the traps is one then, but trying to get rid of stack argument passing to system calls is quite another. This would not be a problem were it not for the prototypes that allowed the compiler to bogusly "optimize" the calls to include register argument passing for system call "functions". The correct way to deal with tis problem is to disable such optimizations, such that each system call becomes a push of the call number and a trap, and can itself be inlined. Probably this requires a #pragma on the compiler's behalf to force the argument push. It's very arguable that the compiler would generate incorrectly window optimized code for inlined system calls at present. Specifically, it would fail to see the need to push the arguments. Even with a workaround that forced the push in the inlined code, the arguments would be incorrectly trated prior to the push, potentitally resulting in pessimal code. > >> > which passes the args correctly (as void *). Then we need to handle > >> > varargs functions and struct padding better. I think all the details > >> > can be hidden in machine-generated functions so that the args structs > >> > and verbose macros to reference them don't have to appear in the core > >> > sources. > > >I have macros that divorce K&R and ANSI vararg behaviour from the code > >itself (I use them for various things myself). Is this what we are > >trying to accomplish? > > No. Varargs syscalls such as open(), fcntl() and shmsys() mess up the > ABI. The args for them have to be copied from different places depending > on codes in the early args. syscall() currently assumes that the args > are on the stack in user space and copies more args than are necessary > and sometimes more than are officially supplied. Varargs for syscall > xxx should handled by fetching them from the appropriate place in > foo_os_syscall_entry_xxx() and passing them in the normal varargs way > to xxx(). This is incorrect. The argument count specified in the systent[] table should result in the correct copyin size. Note that if the size was not validly known in any case, then the amount of stack copied would be mismatched, and some system calls would certainly fail. > > >> > semsys() and shmsys() syscall interfaces are BAD because they > >> > multiplex several syscalls that have different types of args. > >> > There was no reason to duplicate this sysv braindamage but now > >> > we're stuck with it. NetBSD has reimplemented the syscalls properly > >> > as separate syscalls #220-231. > >> > >> I agree. This is yucky! > > > >No, this is good -- system calls are a scarce resource and should be > >consumed conservatively. What's the problem you have with anonymous > >argument vectors using subfunction codes? > > No, this (not syscalls #220-231) is yucky. Multiplexing syscalls > takes more code to handle even incorrectly like it does now. The amount of code is a single computed goto. One might as well argue that locking was "yucky" using this yardstick. But it fails the "yucky" result of varying argument size (it uses a single fixed size structure that does not change). The yardstick is flawed. Depending on the logical grouping of calls, you can easily argue that a compare's worth of overhead is less expensive than a function call's worth, in function preamble/postamble, if nothing else (ignoreing the 3-6 cycles depending on how the call is made). > Non-multiplexed syscalls take one entry in sysent[] and a function > to handle them; multiplexed ones require less entries in sysent[] > and an extra function to demultiplex them. The demultiplexing > function can be simple and unportable like the current ones or > complicated and portable or machine-generated. In general it has > to have code like freebsd_syscall_entry_read() for each of the > variants. What portability problems do you see in the system call multiplex interfaces, and under what circumstances can you cause incorrect code to be generated? > >> We need a better way to handle these syscall subcodes (as SYSV calls 'em). > > > >I guess I don't really understand why these are a problem, unless you > >are trying to do something silly, like prototype them. > > They are a problem because they give more special cases to write code for. As opposed to generating code? I don't see less total code in the long run, and applying a cookie cutter and forcing all the calls to fit the mold is not an optimal approach to solving the problem. The biggest problem I see in the system call interface is the use of a per process call argument stack scratch area makes it per process non-reentrant, or at the very least prevents context change until the arguments have been decoded. This introduces a large latency in async operations through the normal vector, or sync-to-async conversion through an alternate vector. A better resoloution to this particular problem requires per entrancy call argument stack scratch areas, and I see the proposed changes as antithetical to that approach. This is a sacrafice of long term goals for no perceivable short term gain. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Tue Oct 24 14:58:25 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA06051 for cvs-sys-outgoing; Tue, 24 Oct 1995 14:58:25 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA06021 ; Tue, 24 Oct 1995 14:58:05 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA01465; Wed, 25 Oct 1995 07:57:12 +1000 Date: Wed, 25 Oct 1995 07:57:12 +1000 From: Bruce Evans Message-Id: <199510242157.HAA01465@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-cvs-sys@freebsd.org Precedence: bulk >OK. I hate leaving all of the above in for context, but I have to. I left it out to stop the context expanding forever :-). >The disadvantage you cite is false. Internal kernel calls to read >do not follow the same rules on inlining. The inlining is to They can do whatever is convenient. >The problem seems to be one of understanding trap vector argument >decodes. >When a system call is made, arguments are pushed on the user stack >and then the trap vector is called. There is a necessity to copy >the arguments as if they were on the stack down to a kernel space >buffer area because of the address space differences. The amount >that is copied is determined by an integer count of integers: that >is, it is some number 'n' * sizeof(int) bytes that get copied. Only in some ABI's. This is probably the best way, but it may requires messy conversions in the library to put the args on the stack with consistent padding. Since we don't control foreign ABI's we shouldn't assume this. For example, in Linux all the args are passed in registers. In Minix, the args are stored in a syscall-dependent struct and a pointer to the struct is passed in %ebx. The struct is not always nicely padded (it can have packed char and short fields). >This is dependent on the arguments pushed on the stack being >representable as integer values (we are guaranteed this by the >fact that we are calling a non-local function that is not inlined). There is no such guarantee. gcc for the i386 happens to use this slow parameter passing convention for portability. (Unless you compile with -mregparm. -mregparm is officially supported in gcc-2.7.0. It is apparently necessary for OS/2 or Windows-NT.) >[copyin() of the args] >Now each of the arguments are themselves, potentially, pointers to >additional information in call/subcode specific user space structures >that must, additionally be copied in (or out to). Not quite. The args may be padded. In NetBSD for the alpha, the args are apparently padded to 8 bytes and the SCARG macro is mainly to extract the relevant subfield which is usually 4 bytes. There may be complications for endianness. >While BSD could very well benefit from a single verification, avoiding >the mapping issues in copyin/copyout, giving one check instead of two It could benefit most from passing args in registers, as in Linux, so that no copyin() is required. >What does it do? What use is the change? It avoids scattering unportable casts and ugly macros to perform them throughout the "machine-independent" code. Now we have only unportable casts. 4.4lite2 has slightly less unportable casts and ugly macros. NetBSD has much less unportable casts and ugly macros. >If we are trying for this small an incremental improvement, I suggest >spending coding time on getting callee pop working within the kernel >code. It would be a much higher gain for less effort. That will work when I get everything prototyped properly. Prototyping syscalls is one of the easiest parts. >It's very arguable that the compiler would generate incorrectly window >optimized code for inlined system calls at present. Specifically, >it would fail to see the need to push the arguments. Earth to Terry :-). We're talking about inlining syscall handlers, not syscalls. >> No. Varargs syscalls such as open(), fcntl() and shmsys() mess up the >> ABI. The args for them have to be copied from different places depending >> on codes in the early args. syscall() currently assumes that the args >> are on the stack in user space and copies more args than are necessary >> and sometimes more than are officially supplied. Varargs for syscall >> xxx should handled by fetching them from the appropriate place in >> foo_os_syscall_entry_xxx() and passing them in the normal varargs way >> to xxx(). >This is incorrect. The argument count specified in the systent[] table >should result in the correct copyin size. There may be no correct size. A size of 3 ints wouldn't work for open("foo", 0) if the caller has perversely passed 2 args on the stack at the top of the address space. Where are the ABI specs that disallow this? Also, a single number doesn't tell you where the args are. In general you need an offset and a size for each arg on the user stack (let's not worry about endianness conversions :-) and a mapping of user registers to args. >> No, this (not syscalls #220-231) is yucky. Multiplexing syscalls >> takes more code to handle even incorrectly like it does now. >The amount of code is a single computed goto. One might as well Not if there are nontrivial conversions. >What portability problems do you see in the system call multiplex >interfaces, and under what circumstances can you cause incorrect code >to be generated? A reasonable parameter passing convention should put the first few args (a fixed number) in registers but stop at the first `...' arg or the one before (so a variable number of args may be in registers. Where are you going to translate this? Portability problems would result from delaying the translation. Incorrect code would be generated, as usual, due to bugs. >> They are a problem because they give more special cases to write code for. >As opposed to generating code? I don't see less total code in the long >run, and applying a cookie cutter and forcing all the calls to fit the >mold is not an optimal approach to solving the problem. Er, isn't the array of args a mold? I want to make args in the kernel fit the same molds as args in user space: int open(path, flags, ...) is a completely different mold from int open(path, flags, mode) For the former, the compiler should use a special, slow parameter passing convention and pop the args in the caller. For the latter, the compiler should pass at least the first one or two args in registers and pop the args in the callee. Bruce From owner-cvs-sys Tue Oct 24 17:24:44 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13242 for cvs-sys-outgoing; Tue, 24 Oct 1995 17:24:44 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA13227 ; Tue, 24 Oct 1995 17:24:32 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA17462; Tue, 24 Oct 1995 17:16:03 -0700 From: Terry Lambert Message-Id: <199510250016.RAA17462@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Tue, 24 Oct 1995 17:16:03 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510242157.HAA01465@godzilla.zeta.org.au> from "Bruce Evans" at Oct 25, 95 07:57:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10667 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > >When a system call is made, arguments are pushed on the user stack > >and then the trap vector is called. There is a necessity to copy > >the arguments as if they were on the stack down to a kernel space > >buffer area because of the address space differences. The amount > >that is copied is determined by an integer count of integers: that > >is, it is some number 'n' * sizeof(int) bytes that get copied. > > Only in some ABI's. This is probably the best way, but it may > requires messy conversions in the library to put the args on the > stack with consistent padding. Pushing on the stack is a messy conversion? What about dead register usage from not knowing about the stack? I think you are going to have to burn the cycles on an opaque function call in any case. > Since we don't control foreign ABI's we shouldn't assume this. For > example, in Linux all the args are passed in registers. In Minix, > the args are stored in a syscall-dependent struct and a pointer > to the struct is passed in %ebx. The struct is not always nicely > padded (it can have packed char and short fields). That's fine. The size of arguments in iBCS2 and BSD is 'int'. It's either 'int' or 'long' or '*'. So we take a hit when processing these non-standard mechanisms; we do so through the system call table for the ABI, so we will be taking a function encapsulation hit anyway. I think it is unlikely that iBCS2 or Linux develeopement will occur on BSD in a non-emulated environment. > >This is dependent on the arguments pushed on the stack being > >representable as integer values (we are guaranteed this by the > >fact that we are calling a non-local function that is not inlined). > > There is no such guarantee. gcc for the i386 happens to use this > slow parameter passing convention for portability. (Unless you > compile with -mregparm. -mregparm is officially supported in gcc-2.7.0. > It is apparently necessary for OS/2 or Windows-NT.) UNIX typically uses this, period. Stack argument passing to system calls is the way things are done. The use of registers is fine, as long as the interface is general enough. The OS/2 and NT (and Win95) conventions derive from the DOS interrupt mechanisms and require assembly function stubs in any case, even if the routines are then tagged "naked" -- even then, there are problems intordiced that the compiler can't understand a call will trash EAX (and maybe EDX) without hacking an "xor eax,eax" into the thing to make it know that the function to be called trashes it and it can't leave a local variable in it over the call. > >[copyin() of the args] > >Now each of the arguments are themselves, potentially, pointers to > >additional information in call/subcode specific user space structures > >that must, additionally be copied in (or out to). > > Not quite. The args may be padded. In NetBSD for the alpha, the args > are apparently padded to 8 bytes and the SCARG macro is mainly to > extract the relevant subfield which is usually 4 bytes. There may be > complications for endianness. They are padded to the default bus transfer size for the machine, which is supposed to be 'int'. I'd argue that 'int' was the wrong size, not that there was extraneous padding. There is a limit on the address space on the alpha anyway; it's not the full 64 bits. I'd really dealy love to know how there could be an endianess issue, considering system calls are only ever going to run as compiled code on one endianess of machine. > >While BSD could very well benefit from a single verification, avoiding > >the mapping issues in copyin/copyout, giving one check instead of two > > It could benefit most from passing args in registers, as in Linux, so > that no copyin() is required. 1) BSDI binary compatability 2) FreeBSD/NetBSD binary backward compatability 3) Register conversion from a Linux emulation mismatch. 4) Register collision verification in the function so that the register is not used directly for local storage/scratch. 5) Async reentrancy/multithreading reentrancy. It's a can of worms that, frankly, buys so little as to be useless. > >What does it do? What use is the change? > > It avoids scattering unportable casts and ugly macros to perform them > throughout the "machine-independent" code. Now we have only unportable > casts. 4.4lite2 has slightly less unportable casts and ugly macros. > NetBSD has much less unportable casts and ugly macros. The structure casts, I presume? The answer is to compile with the packing being the default for data matchup -- in the alpha case, 64 bits. For devices that need it, use packing #pragma's to tighten them up on a case by case basis, in the header file defining the structure. Aligned element accesses are faster anyway. > >It's very arguable that the compiler would generate incorrectly window > >optimized code for inlined system calls at present. Specifically, > >it would fail to see the need to push the arguments. > > Earth to Terry :-). We're talking about inlining syscall handlers, not > syscalls. Sorry -- you're the one that brought up ABI, which is kernel code, not user space code. The only way you can effect the ABI code is if you call the inlined versions and match the user and kernel usage. Actually, the only way you can guarantee interface usability is to use the inlines to make the calls -- otherwise, your plan to pass in registers fails when you try to call the BSD system call from the ABI system call code. 8-(. > >This is incorrect. The argument count specified in the systent[] table > >should result in the correct copyin size. > > There may be no correct size. A size of 3 ints wouldn't work for > open("foo", 0) if the caller has perversely passed 2 args on the stack > at the top of the address space. Where are the ABI specs that disallow > this? There are none. However, you are wrong; it would work, you'd just get a garbage value (stack direction grows the right direction for the third argument to be optional). Since in that case the garbage value is unreferenced (or the call generated a prototype warning ...not 8-)), then it will work. Getting a bogus value from the stack vs. getting a bogus value from a register is a tossup in any case. > Also, a single number doesn't tell you where the args are. In general > you need an offset and a size for each arg on the user stack (let's not > worry about endianness conversions :-) and a mapping of user registers > to args. I'd really like to see your biendian binary machine that didn't do the switch in the trap code in the kernel (PPC). Throwing that out, the offset is "one stack entry per". The biggest bugger here is preinitialization of the high word of a quad for portability -- but of course, the resulting code fails to operate after certain file lengths are hit instead of immediately, so all that's been done is that the problem has been relocated, not solved. Even assuming the problem is "fixed" by doing this, the only compatability guaranteed is with applications compiled using the same techniques -- that is, applications that don't exist because this is a change in call behaviour as well. I think moving to register parameter passing is too architecture specific. [ ... multiplexed system calls (like, oh, say open with O_CREAT as the multiplexing flag) ... ] > >The amount of code is a single computed goto. One might as well > > Not if there are nontrivial conversions. Then it's a non-trivial case, and splitting it out isn't going to make it more trivial. [ ... and now to the meat ... ] > >What portability problems do you see in the system call multiplex > >interfaces, and under what circumstances can you cause incorrect code > >to be generated? > > A reasonable parameter passing convention should put the first few > args (a fixed number) in registers but stop at the first `...' arg or > the one before (so a variable number of args may be in registers. > Where are you going to translate this? Portability problems would > result from delaying the translation. Incorrect code would be generated, > as usual, due to bugs. I have to point out that it would then be impossible to make system calls without prototype references. If this is a "fix" for the quad word passing problem (which is a "non-use of system call prototype" problem), then, isn't this just making things worse? > > >> They are a problem because they give more special cases to write code for. > > >As opposed to generating code? I don't see less total code in the long > >run, and applying a cookie cutter and forcing all the calls to fit the > >mold is not an optimal approach to solving the problem. > > Er, isn't the array of args a mold? I want to make args in the kernel > fit the same molds as args in user space: > > int open(path, flags, ...) > > is a completely different mold from > > int open(path, flags, mode) > > For the former, the compiler should use a special, slow parameter passing > convention and pop the args in the caller. For the latter, the compiler > should pass at least the first one or two args in registers and pop the > args in the callee. Callee pop only works when using the same stack. When you get to the kernel, the kernel thread (or just process) will be using its own stack, so that argument won't wash. My complaint on callee pop as a more fruitful pursuit was based on kernel-kernel calls, not user-kernel calls. The only problem right now is that the quad argument takes more than one stack position to do its dirty deed. And that's more a result of the thing being an invalid C type than anything else. If were weren't in violation of POSIX/ANSI on quad_t, then it wouldn't be a problem. Probably the correct soloution is to make seperate "quad-knowledgable" functions for the things that take quad arguments. This is actually described in __syscall(2) -- which *guarantees* padding. Right now the screwable functions are truncate, ftruncate, seek, lseek, and mmap -- and mmap() is bogus because of the kernel address space restrictions currently on "vmio". The others are in violation of one or more standards because "quad" isn't an allowable type. Might as well violate them further by using inline references to the __syscall(2) instead of syscall(2) to get to them so that: (1) they are undefined without proper header inclusion, and (2) the padding is guaranteed (as the __syscall(2) states in the man page). That at least would solve the screwups without adding to them. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Wed Oct 25 04:14:46 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA09683 for cvs-sys-outgoing; Wed, 25 Oct 1995 04:14:46 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA09669 ; Wed, 25 Oct 1995 04:14:40 -0700 Date: Wed, 25 Oct 1995 04:14:40 -0700 From: David Greenman Message-Id: <199510251114.EAA09669@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/i386 machdep.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/25 04:14:40 Branch: sys/i386/i386 RELENG_2_1_0 Modified: sys/i386/i386 machdep.c Log: Brought in parts of rev 1.138 and 1.144: fix printing of BIOS disk geoms. From owner-cvs-sys Wed Oct 25 08:09:40 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA18481 for cvs-sys-outgoing; Wed, 25 Oct 1995 08:09:40 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA18456 ; Wed, 25 Oct 1995 08:09:26 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA10257; Thu, 26 Oct 1995 01:06:56 +1000 Date: Thu, 26 Oct 1995 01:06:56 +1000 From: Bruce Evans Message-Id: <199510251506.BAA10257@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-cvs-sys@freebsd.org Precedence: bulk >> >When a system call is made, arguments are pushed on the user stack >> >and then the trap vector is called. There is a necessity to copy >> ... >> Only in some ABI's. This is probably the best way, but it may >> requires messy conversions in the library to put the args on the >> stack with consistent padding. >Pushing on the stack is a messy conversion? What about dead register Deciding what to push is messy. You have to decode the flags that say where the args are. This may have to be written in assembler. >usage from not knowing about the stack? I think you are going to >have to burn the cycles on an opaque function call in any case. I hope that null conversions won't cost anything. Conversions of the form `int fd = uap->fd;' (actually machine-generated code to load fd from an ABI-dependent offset from `void *uap') may even have a negative cost if they happen to load fd into the right register at the right time. >> Since we don't control foreign ABI's we shouldn't assume this. For > >That's fine. The size of arguments in iBCS2 and BSD is 'int'. It's >either 'int' or 'long' or '*'. Which one? In NetBSD it's register_t, which may be longer than an int. This causes problems. >So we take a hit when processing these non-standard mechanisms; we do >so through the system call table for the ABI, so we will be taking >a function encapsulation hit anyway. Inlining should remove the hit. Perhaps given smarter encapsulation functions, the hit from syscall() could be removed: call the encapsulation function directly from Xsyscall() and duplicate what syscall() does (copyin(), etc, iff necessary) in each encapsulation function. >They are padded to the default bus transfer size for the machine, >which is supposed to be 'int'. >I'd argue that 'int' was the wrong size [on the alpha], not that >there was extraneous >padding. This may be true if you control the ABI. >I'd really dealy love to know how there could be an endianess issue, >considering system calls are only ever going to run as compiled code >on one endianess of machine. To run user code on one machine and syscalls on another. I wouldn't want that. >> >What does it do? What use is the change? >> >> It avoids scattering unportable casts and ugly macros to perform them >> throughout the "machine-independent" code. Now we have only unportable >> casts. 4.4lite2 has slightly less unportable casts and ugly macros. >> NetBSD has much less unportable casts and ugly macros. >The structure casts, I presume? Yes. >The answer is to compile with the packing being the default for data >matchup -- in the alpha case, 64 bits. For devices that need it, use >packing #pragma's to tighten them up on a case by case basis, in the >header file defining the structure. That won't help much. The problem is that syscall args don't form a struct. Even if they are in memory, the packing may be different. This can probably be handled by using __attribute__ ((packed)) for every arg to enforce a particular layout. But that would only work with gcc. I suggest using machine-generated code of the form `*(type *)(base + OFFSET)' where `type' and OFFSET depend on the arg. >Aligned element accesses are faster anyway. OFFSET would usually be a multiple of the alignment so it would be easy to calculate :-). >> Earth to Terry :-). We're talking about inlining syscall handlers, not >> syscalls. >Sorry -- you're the one that brought up ABI, which is kernel code, not >user space code. The only way you can effect the ABI code is if you >call the inlined versions and match the user and kernel usage. The ABI is a convention, and can't be changed. >> There may be no correct size. A size of 3 ints wouldn't work for >> open("foo", 0) if the caller has perversely passed 2 args on the stack >> at the top of the address space. Where are the ABI specs that disallow >> this? >There are none. However, you are wrong; it would work, you'd just >get a garbage value (stack direction grows the right direction for >the third argument to be optional). Since in that case the garbage >value is unreferenced (or the call generated a prototype warning >...not 8-)), then it will work. I should get an EFAULT return if the args are at the top of the address space like I said. >> >What portability problems do you see in the system call multiplex >> >interfaces, and under what circumstances can you cause incorrect code >> >to be generated? >> >> A reasonable parameter passing convention should put the first few >> args (a fixed number) in registers but stop at the first `...' arg or >> the one before (so a variable number of args may be in registers. >> Where are you going to translate this? Portability problems would >> result from delaying the translation. Incorrect code would be generated, >> as usual, due to bugs. >I have to point out that it would then be impossible to make system >calls without prototype references. If this is a "fix" for the quad >word passing problem (which is a "non-use of system call prototype" >problem), then, isn't this just making things worse? It requires either prototypes or passing parameters of the correct type just like it always did. Since there is a lot of broken code out there, most compilers use inferior parameter passing conventions to support the broken code. >Callee pop only works when using the same stack. When you get to the >kernel, the kernel thread (or just process) will be using its own stack, >so that argument won't wash. My complaint on callee pop as a more >fruitful pursuit was based on kernel-kernel calls, not user-kernel calls. Of course you wouldn't want to use it across interfaces, but how do you stop a C compiler that is optimized for compiling user code from producing wrong code for interfaces that it doesn't support? (Writing masses of interface code in assembler isn't acceptable.) >Right now the screwable functions are truncate, ftruncate, seek, lseek, >and mmap -- and mmap() is bogus because of the kernel address space >restrictions currently on "vmio". The others are in violation of one >or more standards because "quad" isn't an allowable type. Might as >well violate them further by using inline references to the __syscall(2) >instead of syscall(2) to get to them so that: (1) they are undefined >without proper header inclusion, and (2) the padding is guaranteed >(as the __syscall(2) states in the man page). That at least would solve >the screwups without adding to them. I've thought of changing the compiler to always check format args and print a diagnostic if there is a mismatch for a quad arg. Something similar could be done for the above functions - make them builtins and complain about type mismatches for them. For functions it's easier to silently DTRT (promote the args). Bruce From owner-cvs-sys Wed Oct 25 09:41:30 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25203 for cvs-sys-outgoing; Wed, 25 Oct 1995 09:41:30 -0700 Received: (from jkh@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25188 ; Wed, 25 Oct 1995 09:41:24 -0700 Date: Wed, 25 Oct 1995 09:41:24 -0700 From: "Jordan K. Hubbard" Message-Id: <199510251641.JAA25188@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/isa/matcd matcddrv.h matcd.c options.h matcd.h Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk jkh 95/10/25 09:41:23 Modified: sys/i386/isa/matcd matcd.c options.h Added: sys/i386/isa/matcd matcddrv.h Removed: sys/i386/isa/matcd matcd.h Log: Bring in version 1(26) - considerably less memory usage (and may bring us down to 4MB bootability again). Submitted by: Frank Durda IV From owner-cvs-sys Wed Oct 25 09:43:05 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25393 for cvs-sys-outgoing; Wed, 25 Oct 1995 09:43:05 -0700 Received: (from jkh@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA25382 ; Wed, 25 Oct 1995 09:43:03 -0700 Date: Wed, 25 Oct 1995 09:43:03 -0700 From: "Jordan K. Hubbard" Message-Id: <199510251643.JAA25382@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/conf GENERIC LINT Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk jkh 95/10/25 09:43:03 Modified: sys/i386/conf GENERIC LINT Log: Stable matcd port to 0x230, as per request by Bruce and Frank. Submitted by: Frank Durda IV From owner-cvs-sys Wed Oct 25 10:01:30 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA27235 for cvs-sys-outgoing; Wed, 25 Oct 1995 10:01:30 -0700 Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA27225 ; Wed, 25 Oct 1995 10:01:11 -0700 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id BAA15729; Thu, 26 Oct 1995 01:00:38 +0800 Date: Thu, 26 Oct 1995 01:00:37 +0800 (WST) From: Peter Wemm To: "Jordan K. Hubbard" cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC LINT In-Reply-To: <199510251643.JAA25382@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk On Wed, 25 Oct 1995, Jordan K. Hubbard wrote: > > jkh 95/10/25 09:43:03 > > Modified: sys/i386/conf GENERIC LINT > Log: > Stable matcd port to 0x230, as per request by Bruce and Frank. > Submitted by: Frank Durda IV Hmm. Idea... Before the "grand NMBCLUSTERS reorg", the default number of clusters was 256 (or 512 if GATEWAY). Now, it's 512 + 16 * MAXUSERS (ie: 672 in GENERIC and BOOTMFS). How big is a cluster? I'm not familiar with this area very well, but if it is dynamically allocated does the fixed size of the control structure (mb_map?) take up space? If so, perhaps it might be an idea to put ``options "NMBCLUSTERS=256"'' into the generated BOOTMFS config file? If course, I am not familiar with this area of the kernel, so I may be _way_ off course.. :-) (How much of the VM system is configured before the lower 640K of ram is reclaimed? Could this be a problem?) -Peter From owner-cvs-sys Wed Oct 25 10:20:35 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA28671 for cvs-sys-outgoing; Wed, 25 Oct 1995 10:20:35 -0700 Received: (from jkh@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA28655 ; Wed, 25 Oct 1995 10:20:29 -0700 Date: Wed, 25 Oct 1995 10:20:29 -0700 From: "Jordan K. Hubbard" Message-Id: <199510251720.KAA28655@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/isa/matcd matcd.c options.h matcd.h Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk jkh 95/10/25 10:20:28 Branch: sys/i386/isa/matcd RELENG_2_1_0 Modified: sys/i386/isa/matcd matcd.c options.h Removed: sys/i386/isa/matcd matcd.h Log: Merge from HEAD. From owner-cvs-sys Wed Oct 25 10:29:58 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA29634 for cvs-sys-outgoing; Wed, 25 Oct 1995 10:29:58 -0700 Received: (from jkh@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA29622 ; Wed, 25 Oct 1995 10:29:55 -0700 Date: Wed, 25 Oct 1995 10:29:55 -0700 From: "Jordan K. Hubbard" Message-Id: <199510251729.KAA29622@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/conf GENERIC LINT ATAPI Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk jkh 95/10/25 10:29:55 Branch: sys/i386/conf RELENG_2_1_0 Modified: sys/i386/conf GENERIC LINT Removed: sys/i386/conf ATAPI Log: Merge from HEAD, also eliminate the now-useless ATAPI description. From owner-cvs-sys Wed Oct 25 11:24:07 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA03244 for cvs-sys-outgoing; Wed, 25 Oct 1995 11:24:07 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA03234 ; Wed, 25 Oct 1995 11:24:00 -0700 Date: Wed, 25 Oct 1995 11:24:00 -0700 From: Bruce Evans Message-Id: <199510251824.LAA03234@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/kern tty_pty.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk bde 95/10/25 11:23:59 Modified: sys/kern tty_pty.c Log: Fixed data loss in writes to pty masters. Data was almost always lost at the end of each write for writes of more than 1K. Fixed handling of residual count for early returns in writes to pty masters. It was only adjusted in 2 out of 6 cases. Added prototypes. From owner-cvs-sys Wed Oct 25 11:33:13 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA03626 for cvs-sys-outgoing; Wed, 25 Oct 1995 11:33:13 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA03621 ; Wed, 25 Oct 1995 11:33:07 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA16415; Thu, 26 Oct 1995 04:29:33 +1000 Date: Thu, 26 Oct 1995 04:29:33 +1000 From: Bruce Evans Message-Id: <199510251829.EAA16415@godzilla.zeta.org.au> To: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern tty_subr.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk > Modified: sys/kern tty_subr.c > Log: > Fix clist limits. They were usually one too low. E.g., for a limit of This change should go in 2.1. To see the bug, try od -v /dev/zero >/dev/ptyp8 & cat /dev/ttyp8 | tee foo where ptyp8 is a free pty. This is not the only bug that caused data loss in pty writes. Bruce From owner-cvs-sys Wed Oct 25 12:13:15 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA06418 for cvs-sys-outgoing; Wed, 25 Oct 1995 12:13:15 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA06411 ; Wed, 25 Oct 1995 12:13:08 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA17483; Thu, 26 Oct 1995 05:11:25 +1000 Date: Thu, 26 Oct 1995 05:11:25 +1000 From: Bruce Evans Message-Id: <199510251911.FAA17483@godzilla.zeta.org.au> To: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern tty_pty.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk > Modified: sys/kern tty_pty.c > Log: > Fixed data loss in writes to pty masters. Data was almost always lost > at the end of each write for writes of more than 1K. > > Fixed handling of residual count for early returns in writes to pty masters. > It was only adjusted in 2 out of 6 cases. These changes should be in 2.1 too. Sigh. They should be checked more carefully than the changes in tty_subr.c. I'm not sure what happens in the PF_REMOTE case. cc can only be 0 in that case if the PF_REMOTE flag changed. If that can happen, then cc may be too large to fit in the canq and not everything is written. Bruce From owner-cvs-sys Wed Oct 25 13:56:46 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA14365 for cvs-sys-outgoing; Wed, 25 Oct 1995 13:56:46 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA14340 ; Wed, 25 Oct 1995 13:56:38 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA19391; Wed, 25 Oct 1995 13:47:35 -0700 From: Terry Lambert Message-Id: <199510252047.NAA19391@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Wed, 25 Oct 1995 13:47:35 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510251506.BAA10257@godzilla.zeta.org.au> from "Bruce Evans" at Oct 26, 95 01:06:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 14129 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > >usage from not knowing about the stack? I think you are going to > >have to burn the cycles on an opaque function call in any case. > > I hope that null conversions won't cost anything. Conversions of > the form `int fd = uap->fd;' (actually machine-generated code to > load fd from an ABI-dependent offset from `void *uap') may even > have a negative cost if they happen to load fd into the right > register at the right time. It may have zero cost (a *net* negative cost), I agree. > >> Since we don't control foreign ABI's we shouldn't assume this. For > > > >That's fine. The size of arguments in iBCS2 and BSD is 'int'. It's > >either 'int' or 'long' or '*'. > > Which one? In NetBSD it's register_t, which may be longer than an > int. This causes problems. Yeah. They ignored the definition of "int". That's a problem. The real problem is the lack of atomic sized types and the use of "short" as a synonym for "16 bit value", "long" for "32 bit value" and "quad" for "64 bit value". The real screwup is when int goes greater than 32 bits, the standard *stupidly* requires long to go up as well because it can concieve of a maximally sized type named anything other than "long". That's a bug in the standard in not having mechanisms for obtaining sized types. For a 64 bit int (requiring a 64 bit long), short is either 16 or 32 bits (undefined) and we lose access to either 32 or 16 bit types (respectively). I guess the real question is is there an overflow condition for some (long)lvalue = (int)rvalue; I'd say there isn't, simply because no one has ever expected int's to get bigger than longs, and so the content range isn't there. The only failure modes are in pseudo randomness depending on integer overflow. > >So we take a hit when processing these non-standard mechanisms; we do > >so through the system call table for the ABI, so we will be taking > >a function encapsulation hit anyway. > > Inlining should remove the hit. Perhaps given smarter encapsulation > functions, the hit from syscall() could be removed: call the encapsulation > function directly from Xsyscall() and duplicate what syscall() does > (copyin(), etc, iff necessary) in each encapsulation function. I suppose this assumes that the compiler will correctly adjust the register graph for the inlined assembly's register usage? I don't believe GCC is capable of this now, and I *know* Microsoft's compiler dies when this happens. I think using registers for calls and inlining are antithetical. You may be able to allow the optimizer to choose register passing for you (or not), but the actual choice will vary based on optimization level, etc.. I think this is a tricky failure mode that would require explicit register designation (via #pragma?) which would *decrease* portability, not increase it. > >They are padded to the default bus transfer size for the machine, > >which is supposed to be 'int'. > > >I'd argue that 'int' was the wrong size [on the alpha], not that > >there was extraneous > >padding. > > This may be true if you control the ABI. You *do* control the ABI. You are either running a known ABI paradigm (ie: int push, sizeof(int) == sizeof(register_t), etc.), or you are running a compatability ABI, in which case you know at binary load time and can force alternate argument call gating without much trouble (but some runtime overhead: to be expected in any case of non-native code execution anyway). > >I'd really dealy love to know how there could be an endianess issue, > >considering system calls are only ever going to run as compiled code > >on one endianess of machine. > > To run user code on one machine and syscalls on another. I wouldn't > want that. I agree. The main issue I'm trying to consider here is emulated execution environments on the order of Xenix 286 support. Specifically, I have code for running a process in an emulated x86 environment and making system calls that are serviced by native code. The reason for doing this is running Intel iBCS2 code on PPC and Alpha. Clearly it's insufficient at present, without the ability to do a full 386 emulation, but it's sufficient for kernel interfaces to be allowed to be native rather than emulated as well. It's a sound concept, but it goes to hell under close approach, like what you'd have in wrappering all the system calls, or using register passing. > >> >What does it do? What use is the change? > >> > >> It avoids scattering unportable casts and ugly macros to perform them > >> throughout the "machine-independent" code. Now we have only unportable > >> casts. 4.4lite2 has slightly less unportable casts and ugly macros. > >> NetBSD has much less unportable casts and ugly macros. > > >The structure casts, I presume? > > Yes. Structure casts are not a portability problem (as below). > >The answer is to compile with the packing being the default for data > >matchup -- in the alpha case, 64 bits. For devices that need it, use > >packing #pragma's to tighten them up on a case by case basis, in the > >header file defining the structure. > > That won't help much. The problem is that syscall args don't form > a struct. Even if they are in memory, the packing may be different. This is not allowed to be the case. Either the nature of the push must be changed to ensure a register_t sized push, or the structure packing must be specifiable at declaration time, or (preferrably) both. This is the current case with GCC and AIX/Sun/DEC/SGI compilers, so it shouldn't be an issue. > This can probably be handled by using __attribute__ ((packed)) for > every arg to enforce a particular layout. But that would only work > with gcc. I suggest using machine-generated code of the form > `*(type *)(base + OFFSET)' where `type' and OFFSET depend on the arg. Code readability is an issue. The vnode_if.h file is an allowable exception because of the export layering used in vnode.h's inclusion of the file. The general case of machine generated code is a bad one for code readability. > >Aligned element accesses are faster anyway. > > OFFSET would usually be a multiple of the alignment so it would be > easy to calculate :-). Well, as long as sizeof(int) == sizeof(register_t), it wouldn't ever be an issue in the first place unless you tried to send arguments as themselves and the argument in question too multiple pushes to get there. That's only the quad arguments on Intel, and since the off_t definition is a standards violation, there's no problem with making an interface extension in those cases (already enumerated) to deal with it. > The ABI is a convention, and can't be changed. The ABI is an agreement between user and kernel space, and is abstracted from implementation by (1) binary file identification, (2) execution class, and (3) call gate. That means we can vary it without changing the underlying implementation, with the cost being restricted to the abstraction layering (already in place as additional overhead anyway for ABI class emulation) and additional overhead for non-native ABI's. > >> There may be no correct size. A size of 3 ints wouldn't work for > >> open("foo", 0) if the caller has perversely passed 2 args on the stack > >> at the top of the address space. Where are the ABI specs that disallow > >> this? > > >There are none. However, you are wrong; it would work, you'd just > >get a garbage value (stack direction grows the right direction for > >the third argument to be optional). Since in that case the garbage > >value is unreferenced (or the call generated a prototype warning > >...not 8-)), then it will work. > > I should get an EFAULT return if the args are at the top of the address > space like I said. I think this would be hard to enforce without dictating either stack probes or argument count pushing (ala the VAX Calling Standard) in any implementation. Consider a quad first argument on an Intel architecture. > >I have to point out that it would then be impossible to make system > >calls without prototype references. If this is a "fix" for the quad > >word passing problem (which is a "non-use of system call prototype" > >problem), then, isn't this just making things worse? > > It requires either prototypes or passing parameters of the correct > type just like it always did. Since there is a lot of broken code > out there, most compilers use inferior parameter passing conventions > to support the broken code. And? I don't see that as a problem. It's not possible for FreeBSD to dictate coding practices; unlike Microsoft, it isn't 70% of the market. Because of this, it is necessary to compromise to make the code run. We already do this in a number of cases. You might as well mandate that TERMIOS be the only tty control mechanism, and all applications that expect to run on FreeBSD "must conform". I wouldn't have a problem with an alternate execution class, and potentially trap gate, to cause there to be a "very fast" calling mechanism that is there *as*an*aternative*to*the*default* "portable" calling mechanism. But mandating that the default be such that the majority of code on the net would require patching to make it run (admittedly, mostly header files) is *bogus*. > >Callee pop only works when using the same stack. When you get to the > >kernel, the kernel thread (or just process) will be using its own stack, > >so that argument won't wash. My complaint on callee pop as a more > >fruitful pursuit was based on kernel-kernel calls, not user-kernel calls. > > Of course you wouldn't want to use it across interfaces, but how do > you stop a C compiler that is optimized for compiling user code from > producing wrong code for interfaces that it doesn't support? (Writing > masses of interface code in assembler isn't acceptable.) This is an interesting question... but I can't see a situation where it could be applicable. There *must* be a mechanism for making OS service requests to implement the standard libraries. There is no other option to avoid isolating the program from all of it's I/O (I/O, at least, must use system interfaces, even if everything else is faked, including lying about the time, etc.). The answer to your question is that the compiler must know about some system interface mechanism, then the system must provide the requested mechanism. I object to needing to include standard system call prototypes to allow their use. I put up with lseek/truncate/ftruncate/mmap BS because it's impossible to support all of quads, 32 bit ints, and trap-based call mechanisms and not violate either ANSI C, POSIX or both. I just happen to disagree with where the violation takes place. Note that prototypes of system calls screw up your ability to properly utilize the syscall(2) call gate mechanism the way it was intended. A user space checkpointing mechanism that defines it's own open interface and calls the real open call via syscall (to remember the file names) will fail to compiler when the inlined open conflicts with the user definition. And then you're back to unprototyped or buggered header files (which are *very* system dependent) to implement your application interface. It's a reduction in "portability to BSD". As a "marketing strategy", on should make an OS easy to port to and hard to port from. Idealogically, I'm opposed to the "hard to port from" part of this, but no matter what ideology you follow, making it "hard to port to" is a big, big mistake. > >Right now the screwable functions are truncate, ftruncate, seek, lseek, > >and mmap -- and mmap() is bogus because of the kernel address space > >restrictions currently on "vmio". The others are in violation of one > >or more standards because "quad" isn't an allowable type. Might as > >well violate them further by using inline references to the __syscall(2) > >instead of syscall(2) to get to them so that: (1) they are undefined > >without proper header inclusion, and (2) the padding is guaranteed > >(as the __syscall(2) states in the man page). That at least would solve > >the screwups without adding to them. > > I've thought of changing the compiler to always check format args and > print a diagnostic if there is a mismatch for a quad arg. Something > similar could be done for the above functions - make them builtins > and complain about type mismatches for them. For functions it's > easier to silently DTRT (promote the args). That's one approach, on the order of printf argument checking, and probably requiring a higher-than-default error/warning level to cause to be active. I think most people will fail this test. If you put a mechanism like this in, it's hard to argue that the compiler should bitch at the user instead of just pushing a high order 0 and "making the code work" -- turn the error to a warning. Probably a "correct" approach would be to either (1) push 64 bits per for all arguments, using type identification to decide on pushing a 0 for the quad high order dword or pushing a value that really exists at the time of the call, or (2) choose a different violation of the ANSI C and POSIX standards -- interface extension -- instead of passing quad's for the default truncate/seek/mmap call interfaces. The additional calls would only exist as inlines, not in libc, and would thus be unusable without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And you wouldn't even implement qmmap until the vmio file windowing is fixed in the kernel VM system. I think that changing the interface in such a way as to cause large amounts of "third party" (ie: ftp'able and/or commercial) code to "show its brokenness" is a mistake. The quad system call arguments are mistakes of this family. In any case, I think the benefits are questionable, and should be explored as an execution class other than the default execution class (ABI) before they are integrated. Even after they are integrated, portability would dictate that their use be optional. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Wed Oct 25 14:14:38 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA16098 for cvs-sys-outgoing; Wed, 25 Oct 1995 14:14:38 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA16054 ; Wed, 25 Oct 1995 14:14:28 -0700 From: John Dyson Message-Id: <199510252114.OAA16054@freefall.freebsd.org> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: terry@lambert.org (Terry Lambert) Date: Wed, 25 Oct 1995 14:14:27 -0700 (PDT) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510252047.NAA19391@phaeton.artisoft.com> from "Terry Lambert" at Oct 25, 95 01:47:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1644 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > > Probably a "correct" approach would be to either (1) push 64 bits per > for all arguments, using type identification to decide on pushing a 0 > for the quad high order dword or pushing a value that really exists at > the time of the call, or (2) choose a different violation of the ANSI C > and POSIX standards -- interface extension -- instead of passing quad's > for the default truncate/seek/mmap call interfaces. The additional > calls would only exist as inlines, not in libc, and would thus be unusable > without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And > you wouldn't even implement qmmap until the vmio file windowing is fixed > in the kernel VM system. > Terry, I am confused whe you talk about file windowing. There is absolutely NO windowing or mapping of files into the kernel space except for reading an executables file header. Files take only the KVA space to support the buffer cache and paging I/O. I believe that there are *totally* broken schemes whereby file I/O is done through kernel page faults -- but that is not what we do. All I/O is explicit -- it is nicer that way. Pages from files are simply bulk data residing in VM objects. Some of which have buffers associated with them. The problem with the addressibility in the lower levels of the VM system is that the size of a VM offset is a unsigned long. I do not want to change that to a long long for efficiency reasons. I have a method that will keep the size of the data structure mostly the same, and give a 2^12 increase in the size of the address space. It *might* be a 2.2 thing... John dyson@freebsd.org From owner-cvs-sys Wed Oct 25 14:44:15 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA19829 for cvs-sys-outgoing; Wed, 25 Oct 1995 14:44:15 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA19795 ; Wed, 25 Oct 1995 14:44:06 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19692; Wed, 25 Oct 1995 14:35:48 -0700 From: Terry Lambert Message-Id: <199510252135.OAA19692@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: dyson@freefall.freebsd.org (John Dyson) Date: Wed, 25 Oct 1995 14:35:47 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510252114.OAA16054@freefall.freebsd.org> from "John Dyson" at Oct 25, 95 02:14:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2914 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > > Probably a "correct" approach would be to either (1) push 64 bits per > > for all arguments, using type identification to decide on pushing a 0 > > for the quad high order dword or pushing a value that really exists at > > the time of the call, or (2) choose a different violation of the ANSI C > > and POSIX standards -- interface extension -- instead of passing quad's > > for the default truncate/seek/mmap call interfaces. The additional > > calls would only exist as inlines, not in libc, and would thus be unusable > > without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And > > you wouldn't even implement qmmap until the vmio file windowing is fixed > > in the kernel VM system. > > > Terry, > I am confused whe you talk about file windowing. There is > absolutely NO windowing or mapping of files into the kernel > space except for reading an executables file header. Files > take only the KVA space to support the buffer cache and paging > I/O. I believe that there are *totally* broken schemes whereby > file I/O is done through kernel page faults -- but that is not > what we do. All I/O is explicit -- it is nicer that way. > > Pages from files are simply bulk data residing in VM objects. Some > of which have buffers associated with them. > > The problem with the addressibility in the lower levels of the VM > system is that the > size of a VM offset is a unsigned long. I do not want to change that > to a long long for efficiency reasons. I have a method that > will keep the size of the data structure mostly the same, and > give a 2^12 increase in the size of the address space. > > It *might* be a 2.2 thing... 2^12 * 2^31 = 2^43. 2^43 << 2^63. The problem is for large file systems, and a lesser problem, large files on large file systems (lesser because a file will always be smaller than the FS that contains it). Causing the access to the file to be windowed through the available address space would resolve the problem once and for all and put it at 2^63 -- the highest bit still being reserved for error return on lseek and for indirect block identification. Right now it is impossible to support those files for which quad is a desirable type for off_t because of VM limitations imposed. The imposition is present codified in ffs_vmlimits() in the source file /sys/ufs/ffs/ffs_vfsops.c. The only value of quad is as an annoyance and as a spur to further annoyance and standards violations, as well as an advocacy of evil portability sabatoge to the ABI calling interface. The codification in ffs_vmlimits() is an interface violation in any case: it is a machine architecture dependency, and in acutality a vmio dependency and doesn't belong in the supposedly machine independent FS code anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Wed Oct 25 20:26:24 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23716 for cvs-sys-outgoing; Wed, 25 Oct 1995 20:26:24 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA23693 ; Wed, 25 Oct 1995 20:26:06 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA02246; Thu, 26 Oct 1995 13:21:32 +1000 Date: Thu, 26 Oct 1995 13:21:32 +1000 From: Bruce Evans Message-Id: <199510260321.NAA02246@godzilla.zeta.org.au> To: dyson@freefall.freebsd.org, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, bde@zeta.org.au, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-cvs-sys@freebsd.org Precedence: bulk >2^63 -- the highest bit still being reserved for error return on lseek >and for indirect block identification. The highest bit is not reserved for error return on lseek. Only one value ((off_t)-1) is reserved. >The only value of quad is as an annoyance and as a spur to further It is expedient. Would you prefer off_t to be double? (That's in the ABI; inside the kernel and on disks offsets should be represented in an efficient way, perhaps as quads.) Bruce From owner-cvs-sys Wed Oct 25 22:23:36 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA06164 for cvs-sys-outgoing; Wed, 25 Oct 1995 22:23:36 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA06143 ; Wed, 25 Oct 1995 22:23:14 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA07866; Thu, 26 Oct 1995 15:20:48 +1000 Date: Thu, 26 Oct 1995 15:20:48 +1000 From: Bruce Evans Message-Id: <199510260520.PAA07866@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-cvs-sys@freebsd.org Precedence: bulk >> Which one? In NetBSD it's register_t, which may be longer than an >> int. This causes problems. >Yeah. They ignored the definition of "int". That's a problem. "int" is machine-dependent. On 68000's you would have to support some user compilers using 16 bit ints (for speed) and others using 32 bit ints (for easy porting). We're close to having the same problems with 32 vs 64 bit ints. >The real problem is the lack of atomic sized types and the use of "short" >as a synonym for "16 bit value", "long" for "32 bit value" and "quad" >for "64 bit value". NetBSD has fixed this. It uses the typedefs in (int16_t, int32_t, int64_t) a lot. >The real screwup is when int goes greater than 32 bits, the standard >*stupidly* requires long to go up as well because it can concieve of >a maximally sized type named anything other than "long". This is fundamental. longs are at least as large as ints. >> Inlining should remove the hit. Perhaps given smarter encapsulation >I suppose this assumes that the compiler will correctly adjust the >register graph for the inlined assembly's register usage? I don't >believe GCC is capable of this now, and I *know* Microsoft's compiler >dies when this happens. Everything assumes a correct compiler. gcc justs produces slower code when you give it a register allocation problem that is too hard for it. >I think using registers for calls and inlining are antithetical. You Calls to inline functions don't use the standard calling convention. >> >I'd argue that 'int' was the wrong size [on the alpha], not that >> >there was extraneous >> >padding. >> >> This may be true if you control the ABI. >You *do* control the ABI. You are either running a known ABI paradigm >(ie: int push, sizeof(int) == sizeof(register_t), etc.), or you are >running a compatability ABI, in which case you know at binary load time You know it but you don't control it. >and can force alternate argument call gating without much trouble (but >some runtime overhead: to be expected in any case of non-native code >execution anyway). I've thought of using alternative gates to stop the compatibility interface (for other OS's) from slowing down the standard interface. We plan to use trap gates instead of call gates for standard syscalls. We already support int 0x80 for Linux and NetBSD uses int 0x80 for its native syscalls. If everything used int 0x80, then decoding would be expensive. The expense can be pushed to image activation time using alternative TSS's and gates. We might end up with the following: int 0x80 (trap gate) for native syscalls int 0x80 (trap gate) for NetBSD syscalls int 0x80 (trap gate) for Linux syscalls lcall(7, 0) (call gate) for ibcs2 compatibility and slowness ... >The main issue I'm trying to consider here is emulated execution >environments on the order of Xenix 286 support. Specifically, I >... >to be native rather than emulated as well. It's a sound concept, >but it goes to hell under close approach, like what you'd have in >wrappering all the system calls, or using register passing. Er, you have this exactly backwards. My wrappers provide part of what is required to handle nontrivial conversions from a 16 bit ABI to a 32 bit one. >Structure casts are not a portability problem (as below). >> >The answer is to compile with the packing being the default for data >> >matchup -- in the alpha case, 64 bits. For devices that need it, use >> >packing #pragma's to tighten them up on a case by case basis, in the >> >header file defining the structure. >> >> That won't help much. The problem is that syscall args don't form >> a struct. Even if they are in memory, the packing may be different. >This is not allowed to be the case. Either the nature of the push >must be changed to ensure a register_t sized push, or the structure Yeah, right. Change the Xenix 286 ABI to push 386 register_t's. >packing must be specifiable at declaration time, or (preferrably) both. Packing can't be specified in C. That's why my my machine generated wrappers are required - to provide portability. It isn't worth supporting both because if you support the worst case (weird packing) then it just takes more code to support the array case. >> This can probably be handled by using __attribute__ ((packed)) for >> every arg to enforce a particular layout. But that would only work >> with gcc. I suggest using machine-generated code of the form >> `*(type *)(base + OFFSET)' where `type' and OFFSET depend on the arg. >Code readability is an issue. The vnode_if.h file is an allowable >exception because of the export layering used in vnode.h's inclusion >of the file. The general case of machine generated code is a bad one >for code readability. My ideas for syscalls are based on what is done for vnodes :-). It is possible to do better for syscalls (remove the uap's from the non- machine-generated code) because stacking isn't required. Stacking seems to require passing around uap's because one layer might modify *uap. This is too hard to do with call-by-value function call args. >> The ABI is a convention, and can't be changed. >The ABI is an agreement between user and kernel space, and is abstracted >from implementation by (1) binary file identification, (2) execution >class, and (3) call gate. >That means we can vary it without changing the underlying implementation, >with the cost being restricted to the abstraction layering (already in >place as additional overhead anyway for ABI class emulation) and >additional overhead for non-native ABI's. You can't vary Xenix 286's syscall parameter passing conventions! >> >I have to point out that it would then be impossible to make system >> >calls without prototype references. If this is a "fix" for the quad >> >word passing problem (which is a "non-use of system call prototype" >> >problem), then, isn't this just making things worse? >> >> It requires either prototypes or passing parameters of the correct >> type just like it always did. Since there is a lot of broken code >> out there, most compilers use inferior parameter passing conventions >> to support the broken code. >And? >I don't see that as a problem. It's not possible for FreeBSD to dictate >coding practices; unlike Microsoft, it isn't 70% of the market. Because >of this, it is necessary to compromise to make the code run. We already >do this in a number of cases. I write Standard code and don't wan't it slowed down by inferior parameter passing conventions required for broken code. Unfortunately the parameter passing convention must be the same as the libraries, and the library must use a portable convention internally as well as to interface because using variant conventions would be too hard and isn't fully supported. I don't want the library code cluttered with __attribute((__fast__calling_ convention__)) anyway. >I wouldn't have a problem with an alternate execution class, and potentially >trap gate, to cause there to be a "very fast" calling mechanism that is >there *as*an*aternative*to*the*default* "portable" calling mechanism. >But mandating that the default be such that the majority of code on the >net would require patching to make it run (admittedly, mostly header >files) is *bogus*. The default should be fast. Since the convention is enforced by mostly machine generated glue in /usr/src/lib/libc/i386, the C convention is irrelevant except for its impact on the complexity of the glue. >I object to needing to include standard system call prototypes to allow >their use. I put up with lseek/truncate/ftruncate/mmap BS because it's It isn't required. However, passing of args that have the correct type (after the default promotions) is required. The second arg to lseek must be off_t, not long, except of course if off_t is long. >Note that prototypes of system calls screw up your ability to properly >utilize the syscall(2) call gate mechanism the way it was intended. A The use of syscall() in general requires handling all the messy conversion issues that we have been discussing in your own code. >user space checkpointing mechanism that defines it's own open interface >and calls the real open call via syscall (to remember the file names) >will fail to compiler when the inlined open conflicts with the user >definition. Yes, it can't work in general :-]. It assumes all machines are vaxes. >Probably a "correct" approach would be to either (1) push 64 bits per >for all arguments, using type identification to decide on pushing a 0 >for the quad high order dword or pushing a value that really exists at >the time of the call, or This would be slow and is beside the point. It's easy to implement a good ABI for a particular when you can design it. We'll have just one chance to redesigned the ABI when we switch to int 0x80 syscalls. (2) choose a different violation of the ANSI C >and POSIX standards -- interface extension -- instead of passing quad's POSIX allows most reasonable extensions. >for the default truncate/seek/mmap call interfaces. The additional It even allows nonstandard syscalls such as truncate/mmap :-). >without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And >you wouldn't even implement qmmap until the vmio file windowing is fixed >in the kernel VM system. Linux has llseek. That way leads to many ifdefs. >In any case, I think the benefits are questionable, and should be >explored as an execution class other than the default execution class >(ABI) before they are integrated. Even after they are integrated, >portability would dictate that their use be optional. This discussion has become sidetracked. Please restrict durther discussion to the original point, which is to simplify the apparent interface to syscalls without changing the actual interface at all and without reducing efficiency significantly. Bruce From owner-cvs-sys Wed Oct 25 23:57:45 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA15987 for cvs-sys-outgoing; Wed, 25 Oct 1995 23:57:45 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA15968 ; Wed, 25 Oct 1995 23:57:39 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id XAA09358; Wed, 25 Oct 1995 23:57:38 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id XAA00198; Wed, 25 Oct 1995 23:57:08 -0700 Message-Id: <199510260657.XAA00198@corbin.Root.COM> To: Bruce Evans cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern tty_pty.c In-reply-to: Your message of "Thu, 26 Oct 95 05:11:25 +1000." <199510251911.FAA17483@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 25 Oct 1995 23:57:03 -0700 Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk >> Modified: sys/kern tty_pty.c >> Log: >> Fixed data loss in writes to pty masters. Data was almost always lost >> at the end of each write for writes of more than 1K. >> >> Fixed handling of residual count for early returns in writes to pty masters. >> It was only adjusted in 2 out of 6 cases. > >These changes should be in 2.1 too. Sigh. They should be checked more >carefully than the changes in tty_subr.c. I'm not sure what happens in >the PF_REMOTE case. cc can only be 0 in that case if the PF_REMOTE flag >changed. If that can happen, then cc may be too large to fit in the canq >and not everything is written. I've been testing the changes here. These seem to fix the data loss problems, but a cntrl-C still causes everything to wedge until I kill the 'od' in another window: root 179 112 196 508 ptcout S p0 11:54PM 0:01.71 od -v /dev/zero root 180 112 184 68 ttywai SE+ p0 11:54PM 0:00.54 cat /dev/ttyp8 -DG From owner-cvs-sys Thu Oct 26 00:01:02 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA16167 for cvs-sys-outgoing; Thu, 26 Oct 1995 00:01:02 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA16157 ; Thu, 26 Oct 1995 00:00:58 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id AAA09373; Thu, 26 Oct 1995 00:00:57 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id AAA00212; Thu, 26 Oct 1995 00:00:27 -0700 Message-Id: <199510260700.AAA00212@corbin.Root.COM> To: Bruce Evans cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern tty_pty.c In-reply-to: Your message of "Wed, 25 Oct 95 23:57:03 PDT." <199510260657.XAA00198@corbin.Root.COM> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 26 Oct 1995 00:00:27 -0700 Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk > I've been testing the changes here. These seem to fix the data loss >problems, but a cntrl-C still causes everything to wedge until I kill the >'od' in another window: I forgot to mention that the old code did this, too, so this isn't a new problem. -DG >root 179 112 196 508 ptcout S p0 11:54PM 0:01.71 od -v /dev/zero >root 180 112 184 68 ttywai SE+ p0 11:54PM 0:00.54 cat /dev/ttyp8 > > >-DG From owner-cvs-sys Thu Oct 26 00:40:02 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18858 for cvs-sys-outgoing; Thu, 26 Oct 1995 00:40:02 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA18842 ; Thu, 26 Oct 1995 00:39:53 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA12694; Thu, 26 Oct 1995 17:33:46 +1000 Date: Thu, 26 Oct 1995 17:33:46 +1000 From: Bruce Evans Message-Id: <199510260733.RAA12694@godzilla.zeta.org.au> To: bde@zeta.org.au, davidg@Root.COM Subject: Re: cvs commit: src/sys/kern tty_pty.c Cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk >> I've been testing the changes here. These seem to fix the data loss >>problems, but a cntrl-C still causes everything to wedge until I kill the >>'od' in another window: > I forgot to mention that the old code did this, too, so this isn't a new >problem. >-DG >>root 179 112 196 508 ptcout S p0 11:54PM 0:01.71 od -v /dev/zero >>root 180 112 184 68 ttywai SE+ p0 11:54PM 0:00.54 cat /dev/ttyp8 [This is for od -v /dev/zero >/dev/ptyp8 & cat /dev/ttyp8 I didn't try to fix this. There may be no correct fix. It wouldn't be correct to abort any current i/o and return EOF/EIO for all future i/o on the master pty. Returning EOF for read() would be equivalent to not waiting in ptsclose() and returning EIO for write() would break output intended for other processes. There is interesting behaviour if another process reads from the slave: cat /dev/ttyp8 The od resumes output and the new cat reads it, but this has no effect on the wedged cat. The wedged cat is in last-close() while another process has the device open! Bad things might happen when the last-close() completes. It is probably a bug to allow opens of devices being last-close()d. Bruce From owner-cvs-sys Thu Oct 26 00:40:22 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18917 for cvs-sys-outgoing; Thu, 26 Oct 1995 00:40:22 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18902 ; Thu, 26 Oct 1995 00:40:17 -0700 Date: Thu, 26 Oct 1995 00:40:17 -0700 From: David Greenman Message-Id: <199510260740.AAA18902@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/pci if_de.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/26 00:40:16 Modified: sys/pci if_de.c Log: From Matt Thomas: "I screwed the initialization of the burstsize. Right now it will default to 0 (which can cause corruption problems on high latency PCI buses). It should be set to 8 longwords to avoid problems with certain PCI chipsets." Submitted by: Matt Thomas From owner-cvs-sys Thu Oct 26 00:47:23 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA19848 for cvs-sys-outgoing; Thu, 26 Oct 1995 00:47:23 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA19825 ; Thu, 26 Oct 1995 00:47:18 -0700 Date: Thu, 26 Oct 1995 00:47:18 -0700 From: David Greenman Message-Id: <199510260747.AAA19825@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/pci if_de.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/26 00:47:17 Branch: sys/pci RELENG_2_1_0 Modified: sys/pci if_de.c Log: Brought in 1.35: fix incorrect burstsize initialization. From owner-cvs-sys Thu Oct 26 01:38:40 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA26074 for cvs-sys-outgoing; Thu, 26 Oct 1995 01:38:40 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA26054 ; Thu, 26 Oct 1995 01:38:14 -0700 Date: Thu, 26 Oct 1995 01:38:14 -0700 From: David Greenman Message-Id: <199510260838.BAA26054@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/kern tty_pty.c tty_subr.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/26 01:38:11 Branch: sys/kern RELENG_2_1_0 Modified: sys/kern tty_pty.c tty_subr.c Log: Brought in changes from main branch: fixes for pty data lossage. From owner-cvs-sys Thu Oct 26 02:18:50 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA28192 for cvs-sys-outgoing; Thu, 26 Oct 1995 02:18:50 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA28162 ; Thu, 26 Oct 1995 02:18:06 -0700 Date: Thu, 26 Oct 1995 02:18:06 -0700 From: David Greenman Message-Id: <199510260918.CAA28162@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/ufs/ufs ufs_lookup.c ufs_vnops.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/26 02:17:55 Branch: sys/isofs/cd9660 RELENG_2_1_0 sys/kern RELENG_2_1_0 sys/msdosfs RELENG_2_1_0 sys/nfs RELENG_2_1_0 sys/ufs/ufs RELENG_2_1_0 Modified: sys/isofs/cd9660 cd9660_lookup.c sys/kern vfs_lookup.c vfs_syscalls.c vfs_vnops.c sys/msdosfs msdosfs_vnops.c sys/nfs nfs_vnops.c sys/ufs/ufs ufs_lookup.c ufs_vnops.c Log: Brought in changes from main branch: move FS readonly checks into the filesystem layer to fix related panics from vgone()'d vnodes. From owner-cvs-sys Thu Oct 26 05:44:53 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04620 for cvs-sys-outgoing; Thu, 26 Oct 1995 05:44:53 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA04615 ; Thu, 26 Oct 1995 05:44:39 -0700 Received: by Sysiphos id AA24313 (5.67b/IDA-1.5); Thu, 26 Oct 1995 13:42:45 +0100 Message-Id: <199510261242.AA24313@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Thu, 26 Oct 1995 13:42:45 +0100 In-Reply-To: David Greenman "cvs commit: src/sys/pci if_de.c" (Oct 26, 0:40) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: David Greenman Subject: Re: cvs commit: src/sys/pci if_de.c Cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, matt@lkg.dec.com Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk On Oct 26, 0:40, David Greenman wrote: } Subject: cvs commit: src/sys/pci if_de.c } davidg 95/10/26 00:40:16 } } Modified: sys/pci if_de.c } Log: } From Matt Thomas: } } "I screwed the initialization of the burstsize. Right now it will default } to 0 (which can cause corruption problems on high latency PCI buses). It } should be set to 8 longwords to avoid problems with certain PCI chipsets." } } Submitted by: Matt Thomas There is a global variable for the purpose of determining the maximum burst length. It is currently initialized to 4 longwords, but I guess having it default to 8 would be Ok. (We reduced it to 4 because of a problem reported by Matt Thomas with an old Saturn chip set revision). This variable is supposed to be used by all drivers that support burst transfers. It can be adjusted from the PCI host bridge probe code, if necessary or advantegous. Quoting from /sys/pci/pci.c: /*======================================================== ** ** Variables ** **======================================================== */ /* ** log2 of safe burst len (in words) */ unsigned pci_max_burst_len = 2; /* 2=16Byte, 3=32Byte, 4=64Byte, ... */ I'd really prefer if this mechanism was used ... (I intend to clean up the PCI and NCR code later this year. This will lead to significant simplifications, and I'd like to share as much code as possible with the new EISA and possibly PCMCIA code ...) Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se From owner-cvs-sys Thu Oct 26 06:56:26 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA06853 for cvs-sys-outgoing; Thu, 26 Oct 1995 06:56:26 -0700 Received: (from dyson@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA06844 ; Thu, 26 Oct 1995 06:56:19 -0700 From: John Dyson Message-Id: <199510261356.GAA06844@freefall.freebsd.org> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: terry@lambert.org (Terry Lambert) Date: Thu, 26 Oct 1995 06:56:19 -0700 (PDT) Cc: terry@lambert.org, bde@zeta.org.au, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510252135.OAA19692@phaeton.artisoft.com> from "Terry Lambert" at Oct 25, 95 02:35:47 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2426 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > > 2^12 * 2^31 = 2^43. > 2^43 << 2^63. > > The problem is for large file systems, and a lesser problem, large files > on large file systems (lesser because a file will always be smaller > than the FS that contains it). > > Right now it is impossible to support those files for which quad is > a desirable type for off_t because of VM limitations imposed. The > imposition is present codified in ffs_vmlimits() in the source file > /sys/ufs/ffs/ffs_vfsops.c. > The VM limitations are due to extreme performance hits if we have to go to a (long long) type representation of a page. I propose that we (in fact we will) move from page offsets to page indexes. For a 32 bit machine, it gives us at least 8TB (and probably more with sign extension fixes) for file/filesystem sizes. For a 64 bit machine it would give us even more (by a factor of 4,000,000). As far as the API is concerned, we can use whatever we want -- long, long long, or whatever. We will just have that terrible, limiting capability of supporting only 8TB files on 32 bit machines with 4K pagesizes. We haven't worked on the sign extension problems, because simply we do not support files > 4GB (or is it 2GB???) period right now. I don't believe that there is a problem with block devices (we do NOT use vmio for those.) But additionally we do not support mmaping them right now. > > The codification in ffs_vmlimits() is an interface violation in any > case: it is a machine architecture dependency, and in acutality a > vmio dependency and doesn't belong in the supposedly machine independent > FS code anyway. > I agree - but it made it work for now. The changes have been so vast that there has been significant ugliness added to the code. That is being worked on, and I suggest that if there are some architectural problems that you see -- 'corrected' code would be helpful. Note also some sort of performance analysis and architectural impact review is desirable. All I can say is that I spent nearly a year working on the most horrible OS code that I ever saw -- SVR4, and I don't want us to go down the low performance path that they did. They got both the hackery and low performance. At least we are working on cleaning up the hackery aspects, including that which was inherited from Mach (because of the differences in the philosophy -- Mach VM and the original BSD port was certainly interesting.) John dyson@freebsd.org From owner-cvs-sys Thu Oct 26 11:20:23 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17075 for cvs-sys-outgoing; Thu, 26 Oct 1995 11:20:23 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17068 ; Thu, 26 Oct 1995 11:20:15 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA21395; Thu, 26 Oct 1995 11:11:23 -0700 From: Terry Lambert Message-Id: <199510261811.LAA21395@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Thu, 26 Oct 1995 11:11:23 -0700 (MST) Cc: dyson@freefall.freebsd.org, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, bde@zeta.org.au, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510260321.NAA02246@godzilla.zeta.org.au> from "Bruce Evans" at Oct 26, 95 01:21:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 926 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > >2^63 -- the highest bit still being reserved for error return on lseek > >and for indirect block identification. > > The highest bit is not reserved for error return on lseek. Only one value > ((off_t)-1) is reserved. Sorry; "most significant bit". Or if you prefer "sign bit". There, now the location of the bit itself is sufficiently confused. 8-). At least the number of non-sign bits is invariant, if discontiguous. > >The only value of quad is as an annoyance and as a spur to further > > It is expedient. Would you prefer off_t to be double? (That's in the > ABI; inside the kernel and on disks offsets should be represented in > an efficient way, perhaps as quads.) I would prefer it to be whatever unit was used for stack alignment. In this case, int32 on a 386. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Thu Oct 26 14:33:24 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA27663 for cvs-sys-outgoing; Thu, 26 Oct 1995 14:33:24 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA27633 ; Thu, 26 Oct 1995 14:32:54 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA21688; Thu, 26 Oct 1995 14:24:07 -0700 From: Terry Lambert Message-Id: <199510262124.OAA21688@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: dyson@freefall.freebsd.org (John Dyson) Date: Thu, 26 Oct 1995 14:24:07 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510261356.GAA06844@freefall.freebsd.org> from "John Dyson" at Oct 26, 95 06:56:19 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4035 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > The VM limitations are due to extreme performance hits if we have to > go to a (long long) type representation of a page. I propose that we > (in fact we will) move from page offsets to page indexes. For a 32 bit > machine, it gives us at least 8TB (and probably more with sign extension > fixes) for file/filesystem sizes. For a 64 bit machine it would give us > even more (by a factor of 4,000,000). As far as the API is concerned, > we can use whatever we want -- long, long long, or whatever. We will > just have that terrible, limiting capability of supporting only 8TB files on > 32 bit machines with 4K pagesizes. I think we have to work in the scope of device block addressing, which is 2^31 * 512 or 1TB, as opposed to page addressing at 4TB. The 8TB figure, I think, represents the value without the use of the "improved" UFS indirect block handling that came with 4.4. There are a number of ideas (like page anonymity based page protection) which can't be implemented without a large statistical range for the hash -- typically larger than 32 bits with machine memory sizes running into the 100's of MB. For the Alpha, at least (a nominally 64bit machine), the address range for real memory is restricted to less than 64 bits. The problem that is arising in all these cases is the buffer cache mapping of file data for large ranges requiring a linear relationship throughout the file instead of a smaller linear "window" onto the file. This would require a domain/range based offset + length mapping, allowing multiple mapping windows per file to address the issue completely satisfactorily for 64 bit block and file offsets on 32 bit Intel architectures. Such an approach would not have the "long long" drawbacks that would otherwise be introduced, though there would be *some* (lesser) overhead involved. > We haven't worked on the sign extension problems, because simply we do not > support files > 4GB (or is it 2GB???) period right now. I don't believe that > there is a problem with block devices (we do NOT use vmio for those.) But > additionally we do not support mmaping them right now. It's 2G of file, 1T of file system at present, with a single 32 bit sector offset for a max of 8G based on the dos partitioning and disklabel issues. Ie: a very big partition is allowable, but it must start in the 0-8G range, and disklabellimits the length. I'd like to address the 2G file size problem. The 2G limit currently makes the use of quad off_t's in our internal interfaces a laughable and gratuitous barrier to source compatability with legacy code (the only kind we have, unless you know about a commercial venture that I don't). > The changes have been so vast that there has been significant ugliness > added to the code. That is being worked on, and I suggest that if there > are some architectural problems that you see -- 'corrected' code would be > helpful. Note also some sort of performance analysis and architectural > impact review is desirable. All I can say is that I spent nearly a year > working on the most horrible OS code that I ever saw -- SVR4, and I don't > want us to go down the low performance path that they did. They got both > the hackery and low performance. At least we are working on cleaning up > the hackery aspects, including that which was inherited from Mach (because > of the differences in the philosophy -- Mach VM and the original BSD port > was certainly interesting.) I agree with all of this. It seems that the most interesting places to work are the boundries, and right now the 2G file size limit is one of those, at least for me. At the very least, I'd like to see the system limits on VM mappable space go away as part of the necessary changes. Has any consideration been made to pulling in the NetBSD non-vmio based changes, or to making the vmio/non-vmio switch a bit smoother and less intrusive? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Thu Oct 26 14:41:18 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28259 for cvs-sys-outgoing; Thu, 26 Oct 1995 14:41:18 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28245 ; Thu, 26 Oct 1995 14:41:01 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA21619; Thu, 26 Oct 1995 13:58:06 -0700 From: Terry Lambert Message-Id: <199510262058.NAA21619@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Thu, 26 Oct 1995 13:58:06 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510260520.PAA07866@godzilla.zeta.org.au> from "Bruce Evans" at Oct 26, 95 03:20:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 13134 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > >> Which one? In NetBSD it's register_t, which may be longer than an > >> int. This causes problems. > > >Yeah. They ignored the definition of "int". That's a problem. > > "int" is machine-dependent. On 68000's you would have to support > some user compilers using 16 bit ints (for speed) and others using > 32 bit ints (for easy porting). We're close to having the same > problems with 32 vs 64 bit ints. Well, I'd argue that "max size for a one bus cycle transfer" is an int, so the Lattice/etc. 32 bit 68k int is wrong and the Manx Aztec C 16 bit int is correct. The problem in this case isn't sizeof(int) > sizeof(long), but that sizeof(int) < sizeof(long) | sizeof( void *). > >The real problem is the lack of atomic sized types and the use of "short" > >as a synonym for "16 bit value", "long" for "32 bit value" and "quad" > >for "64 bit value". > > NetBSD has fixed this. It uses the typedefs in > (int16_t, int32_t, int64_t) a lot. Not with 64 bit ints they don't. A 64 bit int means a 64 bit (or greater) long, and either a 16 or 32 bit short. You lose access to either 16 or 32 bit atomic types, period. That's what's broken. > >The real screwup is when int goes greater than 32 bits, the standard > >*stupidly* requires long to go up as well because it can concieve of > >a maximally sized type named anything other than "long". > > This is fundamental. longs are at least as large as ints. This is fundamental to the definition of a long as a non-deterministically sized type. This is in no other way "fundamental". > >I think using registers for calls and inlining are antithetical. You > > Calls to inline functions don't use the standard calling convention. Calls to system calls *must* use *some* calling convention agreed upon in advance and invariant under optimization, or it will be indeterminate under optimization. This is obvious. > >> This may be true if you control the ABI. > > >You *do* control the ABI. You are either running a known ABI paradigm > >(ie: int push, sizeof(int) == sizeof(register_t), etc.), or you are > >running a compatability ABI, in which case you know at binary load time > > You know it but you don't control it. Excuse me? You are attempting to assert exactly that control on the Intel ABI and you are arguing that it can't be done? > >and can force alternate argument call gating without much trouble (but > >some runtime overhead: to be expected in any case of non-native code > >execution anyway). > > I've thought of using alternative gates to stop the compatibility > interface (for other OS's) from slowing down the standard interface. > We plan to use trap gates instead of call gates for standard syscalls. > We already support int 0x80 for Linux and NetBSD uses int 0x80 for > its native syscalls. If everything used int 0x80, then decoding would > be expensive. The expense can be pushed to image activation time using > alternative TSS's and gates. We might end up with the following: > > int 0x80 (trap gate) for native syscalls > int 0x80 (trap gate) for NetBSD syscalls > int 0x80 (trap gate) for Linux syscalls > lcall(7, 0) (call gate) for ibcs2 compatibility and slowness > ... This is the way to do things; my issue was in making the modified calling convention being proposed the default calling convention. > Er, you have this exactly backwards. My wrappers provide part of > what is required to handle nontrivial conversions from a 16 bit > ABI to a 32 bit one. If I produce new code for an emulated environment, I'm *not* going to be doing so in a native environment. The code production will be in the cross environment as well. Wrappering is a non-issue for conversions. Wrappering *is* an issue in code complexity. I believe complexity should be reduced wherever possible -- and this is not done by imposing ever more rigid standards on the programmer, it's done by making the code environment more flexible. What wall time differentials do you expect from the conversion, and why? > > >Structure casts are not a portability problem (as below). > > >> >The answer is to compile with the packing being the default for data > >> >matchup -- in the alpha case, 64 bits. For devices that need it, use > >> >packing #pragma's to tighten them up on a case by case basis, in the > >> >header file defining the structure. > >> > >> That won't help much. The problem is that syscall args don't form > >> a struct. Even if they are in memory, the packing may be different. > > >This is not allowed to be the case. Either the nature of the push > >must be changed to ensure a register_t sized push, or the structure > > Yeah, right. Change the Xenix 286 ABI to push 386 register_t's. That's an emulated environment, and the stack decoding in the kernel must be based on knowledge of the source address. Consider for example a PPC port of FreeBSD capable of running Intel FreeBSD binaries. The capability and the endianess issues must be handled in the ABI call emulation layers. The code will execute in an emulated 386 environment, but all kernel support will be native. This is on the order of an XDR interface that is contextualized for the native byte/word order of the machine instead of network byte order. The point is that the call conversion is layered seperately from the call implementation. Currently, there are a number of internal implemenations that do not understand UIO_SYSSPACE as a copy source/destination for this type of support, but the abstraction of the ABI interface from the implementation interface internal to the kernel itself *must* take this into account. Going to an architecture dependent passing mechanism is a mistake; it greatly complicated the internal interfaces for ABI translation, causing the need for an intermediate layering for native calls. > >packing must be specifiable at declaration time, or (preferrably) both. > > Packing can't be specified in C. That's why my my machine generated > wrappers are required - to provide portability. It isn't worth > supporting both because if you support the worst case (weird packing) > then it just takes more code to support the array case. #pragma. If we are talking about compiler modifications, packing #pragma's are much more generally useful than register call wrappings and the internal code you have suggested for varargs. What is your wrapper for open( const char *, int, ...)? > My ideas for syscalls are based on what is done for vnodes :-). It > is possible to do better for syscalls (remove the uap's from the non- > machine-generated code) because stacking isn't required. Stacking > seems to require passing around uap's because one layer might modify > *uap. This is too hard to do with call-by-value function call args. What about non-native architecture ABI support? > >> The ABI is a convention, and can't be changed. > > >The ABI is an agreement between user and kernel space, and is abstracted > >from implementation by (1) binary file identification, (2) execution > >class, and (3) call gate. > > >That means we can vary it without changing the underlying implementation, > >with the cost being restricted to the abstraction layering (already in > >place as additional overhead anyway for ABI class emulation) and > >additional overhead for non-native ABI's. > > You can't vary Xenix 286's syscall parameter passing conventions! What have I said that implied this? The abstraction layering, since it is *in the kernel* in the class-call handling code, would be transparent. The point is to have a native ABI that matches the kernel exported ABI to reduce overhead for native apps. By going to a register passing mechanism, you destroy this, and complicate the non-native ABI's at the same time... don't you see this as well? > >I wouldn't have a problem with an alternate execution class, and potentially > >trap gate, to cause there to be a "very fast" calling mechanism that is > >there *as*an*aternative*to*the*default* "portable" calling mechanism. > >But mandating that the default be such that the majority of code on the > >net would require patching to make it run (admittedly, mostly header > >files) is *bogus*. > > The default should be fast. Since the convention is enforced by mostly > machine generated glue in /usr/src/lib/libc/i386, the C convention is > irrelevant except for its impact on the complexity of the glue. And the glue in the underlying ABI implementations on the other side of the user/kernel barrier. > >I object to needing to include standard system call prototypes to allow > >their use. I put up with lseek/truncate/ftruncate/mmap BS because it's > > It isn't required. However, passing of args that have the correct type > (after the default promotions) is required. The second arg to lseek > must be off_t, not long, except of course if off_t is long. ??? If it's not required, then either you *aren't* talking about passing arguments to system calls in registers *or* you expect the compiler to "do the right thing" magically. Right now I can write code that makes system calls in assembly. With register passing conventions, I will need to either use library or machine generated external routine calls (unacceptable), or I will have to have documentation of what the compiler has done so that I can do the same thing (non-portable as hell -- ever use M4 to write machine independent assembly code?). > >Note that prototypes of system calls screw up your ability to properly > >utilize the syscall(2) call gate mechanism the way it was intended. A > > The use of syscall() in general requires handling all the messy conversion > issues that we have been discussing in your own code. Why is that? A push is a push. A trap is a trap. The only "messy conversion" is in pushing the arguments on the stack, and I still fail to see the benefit of playing "keep up with Linux" in this regard. > >user space checkpointing mechanism that defines it's own open interface > >and calls the real open call via syscall (to remember the file names) > >will fail to compiler when the inlined open conflicts with the user > >definition. > > Yes, it can't work in general :-]. It assumes all machines are vaxes. This isn't true. Did you even download the Rutger's University process checkpoint/migration code? > >Probably a "correct" approach would be to either (1) push 64 bits per > >for all arguments, using type identification to decide on pushing a 0 > >for the quad high order dword or pushing a value that really exists at > >the time of the call, or > > This would be slow and is beside the point. It's easy to implement a > good ABI for a particular when you can design it. We'll have just > one chance to redesigned the ABI when we switch to int 0x80 syscalls. I don't like it as an option either. I would much rather revert the type of the offset in the standard to the stack alignment type, as it was pre-quad, and define additional quad-knowledgable functions to deal with the quad values which the file system and VM can't currently support anyway. > (2) choose a different violation of the ANSI C > >and POSIX standards -- interface extension -- instead of passing quad's > > POSIX allows most reasonable extensions. Yeah, well using quad for off_t isn't one of them. > >for the default truncate/seek/mmap call interfaces. The additional > > It even allows nonstandard syscalls such as truncate/mmap :-). > > >without prototypes (qtruncate/qftruncate/qseek/qlseek/qmmap). And > >you wouldn't even implement qmmap until the vmio file windowing is fixed > >in the kernel VM system. > > Linux has llseek. That way leads to many ifdefs. It leads to: #ifdef HAS_QUADS #ifndef INT_IS_64 #if BSD44 #define lseek(filedes,offset,whence) qlseek(filedes,offset,whence) #define off_t quad_t #endif /* BSD44*/ #if LINUX #define lseek(filedes,offset,whence) llseek(filedes,offset,whence) #define off_t quad_t #endif /* LINUX*/ #endif /* !INT_IS_64*/ #endif /* HAS_QUADS*/ in one app-specific header file. > >In any case, I think the benefits are questionable, and should be > >explored as an execution class other than the default execution class > >(ABI) before they are integrated. Even after they are integrated, > >portability would dictate that their use be optional. > > This discussion has become sidetracked. Please restrict durther discussion > to the original point, which is to simplify the apparent interface to > syscalls without changing the actual interface at all and without reducing > efficiency significantly. I believe the wrappering to constitute obfuscation, not simplification. There is a difference between conceptual simplification (but no document to reference to determine conception) and implementational simplification. I'm opposed to additional obfuscation of the call interface to allow questionable processor specific optimization to take place at the expense of ABI emulation portability. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Thu Oct 26 16:59:09 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA07338 for cvs-sys-outgoing; Thu, 26 Oct 1995 16:59:09 -0700 Received: (from gibbs@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA07328 ; Thu, 26 Oct 1995 16:59:01 -0700 Date: Thu, 26 Oct 1995 16:59:01 -0700 From: "Justin T. Gibbs" Message-Id: <199510262359.QAA07328@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/pci aic7870.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk gibbs 95/10/26 16:59:00 Modified: sys/dev/aic7xxx aic7xxx.seq Log: Set SCSIGO generically before we determine the phase instead of doing it in each phase routine. Saves a few instructions. Be more careful in how we deal with SXFRCTL0. Or in the control bits of interest instead of using mvi. The kernel driver will set the ULTRAEN bit of SXFRCTL0 if we are using Ultra (20MHz) mode and we don't want to clobber it. In sdtr_to_rate divide by two if we are in ultra mode to get the correct setting since its a 20MHz instead of 10MHz scale. Modified: sys/i386/scsi aic7xxx.c aic7xxx.h Log: Properly deal with the Ultra series of adapters. We should now understand the new seeprom format and negotiate up to 20MHz sync if set in SCSI-Select. Reduce the complexity of the timeout code by running it at splhigh(). Fix a bug that caused rescheduled timeouts at 0 clock ticks in the future causing an infinite loop. Obtained from: Timeout bug noticed by David Greenman and wcarchive. Modified: sys/pci aic7870.c Log: Recognize the aic7880 and 3940 Ultra. If RAMENB is set in devconfig, walk the external SCBs. Some Intel Xpress motherboards set this bit. For external SCBs for the 3940. It doesn't set RAMPS or RAMENB, but does have the ram. From owner-cvs-sys Fri Oct 27 12:08:31 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA13039 for cvs-sys-outgoing; Fri, 27 Oct 1995 12:08:31 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA13006 ; Fri, 27 Oct 1995 12:08:19 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA24658; Sat, 28 Oct 1995 05:03:48 +1000 Date: Sat, 28 Oct 1995 05:03:48 +1000 From: Bruce Evans Message-Id: <199510271903.FAA24658@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-cvs-sys@freebsd.org Precedence: bulk >> >I think using registers for calls and inlining are antithetical. You >> >> Calls to inline functions don't use the standard calling convention. >Calls to system calls *must* use *some* calling convention agreed upon >in advance and invariant under optimization, or it will be indeterminate >under optimization. This is obvious. I was talking about inline functions in the kernel. >> >> This may be true if you control the ABI. >> >> >You *do* control the ABI. You are either running a known ABI paradigm >> >(ie: int push, sizeof(int) == sizeof(register_t), etc.), or you are >> >running a compatability ABI, in which case you know at binary load time >> >> You know it but you don't control it. >Excuse me? You are attempting to assert exactly that control on the >Intel ABI and you are arguing that it can't be done? I was talking about ABI-decoding functions in the kernel (until this discussions got sidetracked into talking about changes to the FreeBSD ABI that we control (FreeBSD != ibcs2)). >> Er, you have this exactly backwards. My wrappers provide part of >> what is required to handle nontrivial conversions from a 16 bit >> ABI to a 32 bit one. >If I produce new code for an emulated environment, I'm *not* going >to be doing so in a native environment. The code production will >be in the cross environment as well. >Wrappering is a non-issue for conversions. Wrappering *is* an issue >in code complexity. I believe complexity should be reduced wherever >possible -- and this is not done by imposing ever more rigid standards >on the programmer, it's done by making the code environment more >flexible. I was talking about reducing code complexity by doing all conversions automatically. >What wall time differentials do you expect from the conversion, and >why? Small. The current unportable code is close to optimal. I wouldn't make it slower. The machine generated code for the current FreeBSD i386 ABI might even be exactly the same as now because all conversions can be reduced to no-ops (this must be possible because the unportable code actually works). >Consider for example a PPC port of FreeBSD capable of running Intel >FreeBSD binaries. The capability and the endianess issues must be >handled in the ABI call emulation layers. The code will execute >in an emulated 386 environment, but all kernel support will be >native. >This is on the order of an XDR interface that is contextualized for >the native byte/word order of the machine instead of network byte >order. >The point is that the call conversion is layered seperately from the >call implementation. Conceptually it's a different layer but it shouldn't be implemented as a separate layer. My idea is to introduce such a conceptual layer somewhere between the syscall entry point (Xsyscall()) and the syscall implementing functions (e.g., read()) and then merge the layers as much as possible using machine-generated code. >> >packing must be specifiable at declaration time, or (preferrably) both. >> >> Packing can't be specified in C. That's why my my machine generated >> wrappers are required - to provide portability. It isn't worth >> supporting both because if you support the worst case (weird packing) >> then it just takes more code to support the array case. >#pragma. If we are talking about compiler modifications, packing #pragma's >are much more generally useful than register call wrappings and the >internal code you have suggested for varargs. All #pragmas are unportable. >What is your wrapper for open( const char *, int, ...)? On the user side (so that the open syscall doesn't have a variable number of args: int open(char const *path, int flags, ...) { va_list argp; int retval; va_start(argp, flags); if (flags & O_CREAT) { /* * This code is written for maximal portability to expose the full * braindamage of the open() interface. Actual implementations * should use one of the easier alternatives and shoot themselves * in the foot by using e.g., `long double' for mode_t. mode_t * is guaranteed to be an arithmetic type (POSIX.1 2.5) and * va_arg is only guaranteed to work for types that are their * own default promotion, so there are many cases. */ /* * Actually I'm too lazy to write all the tests to decide the * promotion of mode_t. Assume it is `promoted_mode_t'. Also * assume that we pass args of fixed size to syscalls and that * registered_mode_t is a type that has that size and holds * mode_t's without loss of information. */ promoted_mode_t mode; registered_mode_t rmode; mode = va_arg(argp, int); rmode = = (registered_mode_t)mode; retval = three_arg_open_syscall(path, flags, rmode); } else retval = two_arg_open_syscall(path, flags); va_end(argp); return retval; } On the kernel side: I can't write it without knowing the target machine. Assuming a simple case where the user side stored the args in a uniform way on the stack or in registers and the lower level kernel code has copied the args from to memory: int syscall_entry_open(struct proc *p, void *argp, int *retval) { char const *path; int flags; promoted_mode_t mode; path = *(char const *)((char *)argp + PATH_OFFSET); flags = *(int *)((char *)argp + FLAGS_OFFSET); if (flags & O_CREAT) { mode = *(promoted_mode_t *)((char *)argp + MODE_OFFSET); return open(p, retval, path, flags, mode); } return open(p, retval, path, flags); } >> My ideas for syscalls are based on what is done for vnodes :-). It >What about non-native architecture ABI support? It requires more code to generate the conversion code. In particular, sizeof() and `struct' can't be used, because the non-native compiler may have completely different behaviour (of course, it's not practical to emulate a machine with a larger address space or ints larger than your quads). >> You can't vary Xenix 286's syscall parameter passing conventions! >What have I said that implied this? The abstraction layering, since >it is *in the kernel* in the class-call handling code, would be >transparent. Perhaps I mean something nonstandard by the ABI. I mean the parameter passing conventions more than the syscall semantics... >The point is to have a native ABI that matches the kernel exported ABI >to reduce overhead for native apps. ... and I mean `I' to stand for interface, not implementation. By definition, the ABI is whatever the kernel exports, and native apps use it. >By going to a register passing mechanism, you destroy this, and complicate >the non-native ABI's at the same time... don't you see this as well? The register passing mechanism for syscalls is a side issue. I only mentioned it as an example of an ABI that we have to emulate (for Linux) and which is better so we should use it. There would be no new complications (except for improvements) because we already support the Linux ABI. >> >I object to needing to include standard system call prototypes to allow >> >their use. I put up with lseek/truncate/ftruncate/mmap BS because it's >> >> It isn't required. However, passing of args that have the correct type >> (after the default promotions) is required. The second arg to lseek >> must be off_t, not long, except of course if off_t is long. >??? If it's not required, then either you *aren't* talking about passing >arguments to system calls in registers *or* you expect the compiler to >"do the right thing" magically. I'm talking about the requirement in C to pass parameters of the correct type (if a prototype is in scope, then there are more correct types). >Right now I can write code that makes system calls in assembly. With >register passing conventions, I will need to either use library or >machine generated external routine calls (unacceptable), or I will have >to have documentation of what the compiler has done so that I can do >the same thing (non-portable as hell -- ever use M4 to write machine >independent assembly code?). It's always been necessary to know what what the compiler does if you write glue functions in assembler. (gcc) inline assembler has many advantages here. You don't need to know what the compiler does (you just tell it how to load syscall args), and one layer of glue can be avoided. >> >Note that prototypes of system calls screw up your ability to properly >> >utilize the syscall(2) call gate mechanism the way it was intended. A >> >> The use of syscall() in general requires handling all the messy conversion >> issues that we have been discussing in your own code. >Why is that? A push is a push. A trap is a trap. >The only "messy conversion" is in pushing the arguments on the stack, >and I still fail to see the benefit of playing "keep up with Linux" >in this regard. syscall() is written in C, so the compiler can pass args to it anywhere it wants. syscall() then has the task of putting the args where the kernel expects them. In general, it would have to know about all syscalls and do the inverse of the conversions that I'm talking about doing in the kernel. Consider a 68K compiler that passes the first 2 pointer args (if any) in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other args on the stack. How are you going to push the args in syscall()? Hint: you'll need to know the arg types of all syscalls. >> (2) choose a different violation of the ANSI C >> >and POSIX standards -- interface extension -- instead of passing quad's >> >> POSIX allows most reasonable extensions. >Yeah, well using quad for off_t isn't one of them. Would you prefer double? Allowing it seems to be a bug in POSIX.1-1990. More things would break. >> Linux has llseek. That way leads to many ifdefs. >It leads to: >#ifdef HAS_QUADS >#ifndef INT_IS_64 >#if BSD44 >#define lseek(filedes,offset,whence) qlseek(filedes,offset,whence) >#define off_t quad_t >#endif /* BSD44*/ >#if LINUX >#define lseek(filedes,offset,whence) llseek(filedes,offset,whence) >#define off_t quad_t >#endif /* LINUX*/ >#endif /* !INT_IS_64*/ >#endif /* HAS_QUADS*/ >in one app-specific header file. It's worse than that. Linux doesn't have quads. Applications have to use pairs of longs and do their own (equivalent to quad) arithmetic on them. So ifdefs like the above all through the code might be necessary. >I believe the wrappering to constitute obfuscation, not simplification. >There is a difference between conceptual simplification (but no >document to reference to determine conception) and implementational >simplification. >I'm opposed to additional obfuscation of the call interface to >allow questionable processor specific optimization to take place >at the expense of ABI emulation portability. We're in violent agreement :-). I'd like to hide the current unportabilities and scattered casts in a conceptually simple layer. This requires a complicated and unportable implementation for the layer. Bruce From owner-cvs-sys Fri Oct 27 12:40:04 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA15311 for cvs-sys-outgoing; Fri, 27 Oct 1995 12:40:04 -0700 Received: from revenue.regent.e-technik.tu-muenchen.de (revenue.regent.e-technik.tu-muenchen.de [129.187.231.161]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA15298 ; Fri, 27 Oct 1995 12:39:56 -0700 Received: from vector.eikon.e-technik.tu-muenchen.de (vector.eikon.e-technik.tu-muenchen.de [129.187.142.36]) by revenue.regent.e-technik.tu-muenchen.de (8.6.12/8.6.9) with ESMTP id UAA29029; Fri, 27 Oct 1995 20:37:52 +0100 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with SMTP id RAA01779; Fri, 27 Oct 1995 17:46:04 +0100 Message-Id: <199510271646.RAA01779@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: Bruce Evans cc: davidg@Root.COM, CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern tty_pty.c Reply-To: "Julian H. Stacey" X-Organisation: Vector Systems Ltd, Holz Strasse 27d, 80469 Munich, Germany X-Occupation: Internet Unix C & Systems Engineering Consultant X-Phone: +49 89 268616 Fax: +49 89 2608126 Timezone: GMT+1 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Thu, 26 Oct 1995 17:33:46 +1000." <199510260733.RAA12694@godzilla.zeta.org.au> Date: Fri, 27 Oct 1995 17:46:04 +0100 From: "Julian H. Stacey" Sender: owner-cvs-sys@freebsd.org Precedence: bulk > Message-Id: <199510260733.RAA12694@godzilla.zeta.org.au> > ... and the new cat reads it, but this has no effect on > the wedged cat. The wedged cat is in ... Wedged cats are best, keeps their claws & teeth confined ;-) Julian S From owner-cvs-sys Fri Oct 27 13:20:08 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA17912 for cvs-sys-outgoing; Fri, 27 Oct 1995 13:20:08 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA17891 ; Fri, 27 Oct 1995 13:19:55 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23809; Fri, 27 Oct 1995 13:09:47 -0700 From: Terry Lambert Message-Id: <199510272009.NAA23809@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Fri, 27 Oct 1995 13:09:46 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510271903.FAA24658@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 05:03:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9639 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > >What wall time differentials do you expect from the conversion, and > >why? > > Small. The current unportable code is close to optimal. I wouldn't > make it slower. The machine generated code for the current FreeBSD > i386 ABI might even be exactly the same as now because all conversions > can be reduced to no-ops (this must be possible because the unportable > code actually works). The reason for my asking was to determine if you believed this to be a speed optimization (which I might be able to get behind) or if it's simply an interface change (which I suspected it was, and so it's now an issue of whether it's gratuitious or if ti really buys something). [ ... reordered for coherency ... ] > >#pragma. If we are talking about compiler modifications, packing #pragma's > >are much more generally useful than register call wrappings and the > >internal code you have suggested for varargs. > > All #pragmas are unportable. All packing assumptions are unportable. I argue that a #pragma beats the __attrib crap because a compiler may ignore it. > Conceptually it's a different layer but it shouldn't be implemented as > a separate layer. My idea is to introduce such a conceptual layer > somewhere between the syscall entry point (Xsyscall()) and the syscall > implementing functions (e.g., read()) and then merge the layers as > much as possible using machine-generated code. [ ...] > >What is your wrapper for open( const char *, int, ...)? > > On the user side (so that the open syscall doesn't have a variable number > of args: > > int open(char const *path, int flags, ...) Whoah. Right there we have a problem. I'll be happy to give you my varrarg macros to make them ANSI-C and K&R C independent. Usign varrargs in an ANSI dependent fashion reduces portability to non-ANIC-C envirnments. The things belong in ctypes.h anyway. [ ... ] > int open(char const *path, int flags, ...) > { > va_list argp; > int retval; > > va_start(argp, flags); > if (flags & O_CREAT) { > promoted_mode_t mode; > registered_mode_t rmode; > > mode = va_arg(argp, int); > rmode = = (registered_mode_t)mode; > retval = three_arg_open_syscall(path, flags, rmode); > } else > retval = two_arg_open_syscall(path, flags); > va_end(argp); > return retval; > } I think that the system call itself could make the decision based on the O_CREAT itself. I'd suggest changing: > retval = three_arg_open_syscall(path, flags, rmode); > } else > retval = two_arg_open_syscall(path, flags); to: > retval = three_arg_open_syscall(path, flags, rmode); > } else > retval = three_arg_open_syscall(path, flags, 0); [ ... ] > On the kernel side: I can't write it without knowing the target machine. > Assuming a simple case where the user side stored the args in a uniform > way on the stack or in registers and the lower level kernel code has > copied the args from to memory: [ ... ] > path = *(char const *)((char *)argp + PATH_OFFSET); > flags = *(int *)((char *)argp + FLAGS_OFFSET); > mode = *(promoted_mode_t *)((char *)argp + MODE_OFFSET); Forgive me... but this is butt-ugly. I mean really, *really* butt-ugly. I find this horribly obfucated. This is exactly what I feared when I objected. 8-(. BTW: the 'path' line is broken... "*(const char **)", maybe? Since the stack variable assigns are based on an entry argument, then the assignments can be done at declaration time. Therefore something like: #define ARG(argtype,arg) \ argtype arg = *(__CONCAT(argtype,*))((char *)argp + \ __CONCAT(arg,_OFFSET)); Then: > int syscall_entry_open(struct proc *p, void *argp, int *retval) > { > ARG( char const *, PATH); > ARG( int, FLAGS); > ARG( promoted_mode_t, MODE); > > if (flags & O_CREAT) { > return open(p, retval, PATH, FLAGS, MODE); > } > return open(p, retval, PATH, FLAGS); > } Would be more readable. I don't understand why passing a bogus mode to open when O_CREAT wasn't present would be a problem??? That is, why not: > int syscall_entry_open(struct proc *p, void *argp, int *retval) > { > ARG( char const *, PATH); > ARG( int, FLAGS); > ARG( promoted_mode_t, MODE); > > return open(p, retval, PATH, FLAGS, MODE); > } ??? Hell: #define SYSCALL_ENTRY(function) \ int __CONCAT(syscall_entry_,function) \ (struct proc *p, void *argp, int *retval) > SYSCALL_ENTRY(open) > { > ARG( char const *, PATH); > ARG( int, FLAGS); > ARG( promoted_mode_t, MODE); > > return open(p, retval, PATH, FLAGS, MODE); > } > >What about non-native architecture ABI support? > > It requires more code to generate the conversion code. In particular, > sizeof() and `struct' can't be used, because the non-native compiler > may have completely different behaviour (of course, it's not practical > to emulate a machine with a larger address space or ints larger than > your quads). I agree with the practicality argument: after all, that's exactly what we are doing already with lseek, et al. 8-). I know the XDR aspects re structure packing are an issue, though since you seem to be assuming the same compiler source everywhere (GCC), I don't see where a packing paragma would be more of an issue than any other approach requiring compiler modifications. > >By going to a register passing mechanism, you destroy this, and complicate > >the non-native ABI's at the same time... don't you see this as well? > > The register passing mechanism for syscalls is a side issue. I only > mentioned it as an example of an ABI that we have to emulate (for Linux) > and which is better so we should use it. There would be no new > complications (except for improvements) because we already support the > Linux ABI. I'm glad to see this. I think, though, the rationale for the changes still hasn't been clarified. > >??? If it's not required, then either you *aren't* talking about passing > >arguments to system calls in registers *or* you expect the compiler to > >"do the right thing" magically. > > I'm talking about the requirement in C to pass parameters of the correct > type (if a prototype is in scope, then there are more correct types). OK. I buy this too. But this implies that if there is not a prototype in scope, a function that uses a type that is not correct without a prototype in scope should not generate a bogus call reference. This was my point on the quad crap and reverting the default interfaces to POSIX compliance (and double doesn't count unless you can use it without a prototype in scope). > >Right now I can write code that makes system calls in assembly. With > >register passing conventions, I will need to either use library or > >machine generated external routine calls (unacceptable), or I will have > >to have documentation of what the compiler has done so that I can do > >the same thing (non-portable as hell -- ever use M4 to write machine > >independent assembly code?). > > It's always been necessary to know what what the compiler does if you > write glue functions in assembler. (gcc) inline assembler has many > advantages here. You don't need to know what the compiler does (you > just tell it how to load syscall args), and one layer of glue can be > avoided. But *lord*! Having to happen to know what register the argument goes into before the call! > >> >Note that prototypes of system calls screw up your ability to properly > >> >utilize the syscall(2) call gate mechanism the way it was intended. A > >> > >> The use of syscall() in general requires handling all the messy conversion > >> issues that we have been discussing in your own code. > > >Why is that? A push is a push. A trap is a trap. > > >The only "messy conversion" is in pushing the arguments on the stack, > >and I still fail to see the benefit of playing "keep up with Linux" > >in this regard. > > syscall() is written in C, so the compiler can pass args to it anywhere it > wants. syscall() then has the task of putting the args where the kernel > expects them. In general, it would have to know about all syscalls and > do the inverse of the conversions that I'm talking about doing in the > kernel. Bletch. How does Linux deal with it (my linux box is running Win95 right now)? > Consider a 68K compiler that passes the first 2 pointer args (if any) > in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other > args on the stack. How are you going to push the args in syscall()? > Hint: you'll need to know the arg types of all syscalls. That's an evil way to pass arguments, then. 8-(. > >> (2) choose a different violation of the ANSI C > >> >and POSIX standards -- interface extension -- instead of passing quad's > >> > >> POSIX allows most reasonable extensions. > > >Yeah, well using quad for off_t isn't one of them. > > Would you prefer double? Allowing it seems to be a bug in POSIX.1-1990. > More things would break. No. I'd prefer int/long. > It's worse than that. Linux doesn't have quads. Applications have to use > pairs of longs and do their own (equivalent to quad) arithmetic on them. > So ifdefs like the above all through the code might be necessary. Linux has GCC. Linux has quads. > We're in violent agreement :-). I'd like to hide the current > unportabilities and scattered casts in a conceptually simple layer. I agree. > This requires a complicated and unportable implementation for the > layer. I don't agree. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Fri Oct 27 15:00:32 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA24570 for cvs-sys-outgoing; Fri, 27 Oct 1995 15:00:32 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA24532 ; Fri, 27 Oct 1995 15:00:04 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA29637; Sat, 28 Oct 1995 07:57:34 +1000 Date: Sat, 28 Oct 1995 07:57:34 +1000 From: Bruce Evans Message-Id: <199510272157.HAA29637@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-cvs-sys@freebsd.org Precedence: bulk >> All #pragmas are unportable. >All packing assumptions are unportable. I argue that a #pragma beats >the __attrib crap because a compiler may ignore it. A compiler may exec /usr/games/hack to handle every pragma. gcc used to do this. >> path = *(char const *)((char *)argp + PATH_OFFSET); >> flags = *(int *)((char *)argp + FLAGS_OFFSET); >> mode = *(promoted_mode_t *)((char *)argp + MODE_OFFSET); >Forgive me... but this is butt-ugly. I mean really, *really* butt-ugly. >I find this horribly obfucated. This is exactly what I feared when I >objected. 8-(. It's machine generated. It looks better than va_arg(). Don't look at it. >BTW: the 'path' line is broken... "*(const char **)", maybe? Oops. >Since the stack variable assigns are based on an entry argument, then >the assignments can be done at declaration time. Therefore something >like: >#define ARG(argtype,arg) \ > argtype arg = *(__CONCAT(argtype,*))((char *)argp + \ > __CONCAT(arg,_OFFSET)); Assignment at declaration time is consider bad style by the 4.4lite2 style guide and by me. The offsets would actually be literal numbers. They are too hard to create using macros. >I don't understand why passing a bogus mode to open when O_CREAT wasn't >present would be a problem??? >That is, why not: >> int syscall_entry_open(struct proc *p, void *argp, int *retval) >> { >> ARG( char const *, PATH); >> ARG( int, FLAGS); >> ARG( promoted_mode_t, MODE); >> >> return open(p, retval, PATH, FLAGS, MODE); >> } The last ARG() might cause a fatal trap if the arg doesn't exist. It might be worth guaranteeing that argp points to a safe place to ARG() can't trap here. But then the caller might have to do more work to provide a safe place or recover from the trap. This is currently handled very efficiently by copyin() recovering from traps if the user doesn't supply enough args. >Hell: >#define SYSCALL_ENTRY(function) \ > int __CONCAT(syscall_entry_,function) \ > (struct proc *p, void *argp, int *retval) >> SYSCALL_ENTRY(open) >> { >> ARG( char const *, PATH); >> ARG( int, FLAGS); >> ARG( promoted_mode_t, MODE); >> >> return open(p, retval, PATH, FLAGS, MODE); >> } This would require large table of #defines of OFFSETs. I prefer to use literal offsets. >I know the XDR aspects re structure packing are an issue, though since >you seem to be assuming the same compiler source everywhere (GCC), No, the OFFSETs depend on the compiler. I assumed the same endianness in my example, but endianness changes can be handled by more complicated ARG() code. Pointer alignment for *(foo_t *) is unlikely to be a problem because the args are usually laid out so that they can be accessed. >I don't see where a packing paragma would be more of an issue than >any other approach requiring compiler modifications. It would take about the same work to machine-generate all the pragmas and padding as to machine-generate all the offsets, e.g., #pragma pack(0) /* or whatever stops all packing */ struct read_args { char const *path; int flags; char pad1[4]; /* little endian, 4 byte ints, 8 byte regs */ mode_t mode; char pad2[6]; }; vs. #define read_path_OFFSET 0 #define read_path_type char const * #define read_flags_OFFSET 8 #define read_flags_type int #define read_mode_OFFSET 16 #define read_mode_type mode_t >> The register passing mechanism for syscalls is a side issue. I only >> mentioned it as an example of an ABI that we have to emulate (for Linux) >> and which is better so we should use it. There would be no new >> complications (except for improvements) because we already support the >> Linux ABI. >I'm glad to see this. I think, though, the rationale for the changes >still hasn't been clarified. `lcall' allow users to trace into syscalls. This can be recovered from but is ugly. Trap gates don't have this problem. NetBSD and Linux already use trap gates for their native system calls and we don't want to be uglier or slower than NetBSD or Linux :-). We need to support trap gates for emulation anyway. If we change to trap gates then we should consider changing other parts of the syscall interface. We don't need to copy NetBSD's or Linux's interface except for emulation. >This was my point on the quad crap and reverting the default interfaces >to POSIX compliance (and double doesn't count unless you can use it >without a prototype in scope). if (lseek(fd, (off_t)foo, SEEK_SET) == (off_t)-1) perror("lseek"); works without a prototype in scope even if off_t is quad or double. >> syscall() is written in C, so the compiler can pass args to it anywhere it >> wants. syscall() then has the task of putting the args where the kernel >> expects them. In general, it would have to know about all syscalls and >> do the inverse of the conversions that I'm talking about doing in the >> kernel. >Bletch. How does Linux deal with it (my linux box is running Win95 >right now)? i386's are enough like vaxes and gcc uses stupid enough function call conventions for there to be no problems. Just put the first arg in the first register, etc. >> Consider a 68K compiler that passes the first 2 pointer args (if any) >> in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other >> args on the stack. How are you going to push the args in syscall()? >> Hint: you'll need to know the arg types of all syscalls. >That's an evil way to pass arguments, then. 8-(. But not stupid :-). >> It's worse than that. Linux doesn't have quads. Applications have to use >> pairs of longs and do their own (equivalent to quad) arithmetic on them. >> So ifdefs like the above all through the code might be necessary. >Linux has GCC. Linux has quads. I thought it doesn't use them for llseek. I guess it doesn't matter. Two longs together look like a quad. Bruce From owner-cvs-sys Fri Oct 27 17:00:47 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA00346 for cvs-sys-outgoing; Fri, 27 Oct 1995 17:00:47 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA00329 ; Fri, 27 Oct 1995 17:00:26 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA24249; Fri, 27 Oct 1995 16:50:51 -0700 From: Terry Lambert Message-Id: <199510272350.QAA24249@phaeton.artisoft.com> Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] To: bde@zeta.org.au (Bruce Evans) Date: Fri, 27 Oct 1995 16:50:50 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu In-Reply-To: <199510272157.HAA29637@godzilla.zeta.org.au> from "Bruce Evans" at Oct 28, 95 07:57:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5255 Sender: owner-cvs-sys@freebsd.org Precedence: bulk > >> All #pragmas are unportable. > > >All packing assumptions are unportable. I argue that a #pragma beats > >the __attrib crap because a compiler may ignore it. > > A compiler may exec /usr/games/hack to handle every pragma. gcc used > to do this. It doesn't any more. Stahlman did this to be an ass. > >I don't understand why passing a bogus mode to open when O_CREAT wasn't > >present would be a problem??? > > >That is, why not: > > >> int syscall_entry_open(struct proc *p, void *argp, int *retval) > >> { > >> ARG( char const *, PATH); > >> ARG( int, FLAGS); > >> ARG( promoted_mode_t, MODE); > >> > >> return open(p, retval, PATH, FLAGS, MODE); > >> } > > The last ARG() might cause a fatal trap if the arg doesn't exist. It > might be worth guaranteeing that argp points to a safe place to ARG() > can't trap here. But then the caller might have to do more work to > provide a safe place or recover from the trap. This is currently > handled very efficiently by copyin() recovering from traps if the user > doesn't supply enough args. Hence, my use of the 0 argument on the open in user space in the last posting to provide a valid call on vararg. The open(2) call is not a traditional vararg -- it's a limited one. The "..." in its case means "0 or one argument here" instead of "0 or n arguments here". I don't know of a real vararg system call. > >> SYSCALL_ENTRY(open) > >> { > >> ARG( char const *, PATH); > >> ARG( int, FLAGS); > >> ARG( promoted_mode_t, MODE); > >> > >> return open(p, retval, PATH, FLAGS, MODE); > >> } > > This would require large table of #defines of OFFSETs. I prefer to use > literal offsets. Keep all paths at the same offset, etc. > > >I know the XDR aspects re structure packing are an issue, though since > >you seem to be assuming the same compiler source everywhere (GCC), > > No, the OFFSETs depend on the compiler. I assumed the same endianness > in my example, but endianness changes can be handled by more complicated > ARG() code. Pointer alignment for *(foo_t *) is unlikely to be a problem > because the args are usually laid out so that they can be accessed. Yeah. Only makes sense. Actually, MSC doesn't align stuff correctly. They (Microsoft) pad many things to even alignment boundries, but structure contents themselves are tightly packed. One ABI to consider is WINE. > >I don't see where a packing paragma would be more of an issue than > >any other approach requiring compiler modifications. > > It would take about the same work to machine-generate all the pragmas > and padding as to machine-generate all the offsets, e.g., > > #pragma pack(0) /* or whatever stops all packing */ > struct read_args { > char const *path; > int flags; > char pad1[4]; /* little endian, 4 byte ints, 8 byte regs */ > mode_t mode; > char pad2[6]; > }; That would be better expressed as: > #pragma pack(8) /* quad stack alignment, pointers are quads*/ > struct read_args { > char const *path; > int flags; > mode_t mode; > }; [ ... ] > >I'm glad to see this. I think, though, the rationale for the changes > >still hasn't been clarified. > > `lcall' allow users to trace into syscalls. This can be recovered from > but is ugly. Trap gates don't have this problem. NetBSD and Linux > already use trap gates for their native system calls and we don't want > to be uglier or slower than NetBSD or Linux :-). We need to support > trap gates for emulation anyway. If we change to trap gates then we > should consider changing other parts of the syscall interface. We don't > need to copy NetBSD's or Linux's interface except for emulation. I understand the rationale for considering the changes. I don't understand the rationale for making them. It seems the rationale is "to compete with NetBSD and Linux regarding speed". Is this correct? I personally don't find that compelling (that's not to say that the majority doesn't outweigh me on this -- only that it does not convince me, personally). > >This was my point on the quad crap and reverting the default interfaces > >to POSIX compliance (and double doesn't count unless you can use it > >without a prototype in scope). > > if (lseek(fd, (off_t)foo, SEEK_SET) == (off_t)-1) > perror("lseek"); > > works without a prototype in scope even if off_t is quad or double. But violates POSIX (in the quad case) or the spirit of POSIX (in the double case -- you yourself suggested that this is probably an error in the spec). > >> Consider a 68K compiler that passes the first 2 pointer args (if any) > >> in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other > >> args on the stack. How are you going to push the args in syscall()? > >> Hint: you'll need to know the arg types of all syscalls. > > >That's an evil way to pass arguments, then. 8-(. > > But not stupid :-). OK. I admit it's probably minisculely faster. Is it worth the clutter of the xxx_OFFSET and the xxx_type and the unreadable glue routines to get that miniscule speed "improvement"? Just my opinion, but I think the answer is "no". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-cvs-sys Fri Oct 27 23:27:20 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA16804 for cvs-sys-outgoing; Fri, 27 Oct 1995 23:27:20 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA16766 ; Fri, 27 Oct 1995 23:27:05 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA16949; Sat, 28 Oct 1995 16:12:09 +1000 Date: Sat, 28 Oct 1995 16:12:09 +1000 From: Bruce Evans Message-Id: <199510280612.QAA16949@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Cc: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Sender: owner-cvs-sys@freebsd.org Precedence: bulk >> >I don't understand why passing a bogus mode to open when O_CREAT wasn't >> >present would be a problem??? >... >Hence, my use of the 0 argument on the open in user space in the last >posting to provide a valid call on vararg. The open(2) call is not The difficulty is to extract the 3rd arg if it exists. >a traditional vararg -- it's a limited one. The "..." in its case >means "0 or one argument here" instead of "0 or n arguments here". This only reduces the difficulty. In general you might have to decode all previous args to decide how to extract eacg arg. >I don't know of a real vararg system call. Grepping for \.\.\. in shows the following: open, fcntl, ioctl, msgsys, semsys, shmsys. The last 3 have more than one varargs arg. >> >> SYSCALL_ENTRY(open) >> >> { >> >> ARG( char const *, PATH); >> >> ARG( int, FLAGS); >> >> ARG( promoted_mode_t, MODE); >> >> >> >> return open(p, retval, PATH, FLAGS, MODE); >> >> } >> >> This would require large table of #defines of OFFSETs. I prefer to use >> literal offsets. >Keep all paths at the same offset, etc. You can't. The offsets depend on the ABI. In particular they depend on the word size and endianness even if the packing is the natural one. >Actually, MSC doesn't align stuff correctly. They (Microsoft) pad many >things to even alignment boundries, but structure contents themselves >are tightly packed. This is probably inherited from 16-bit packing and calling conventions. >> #pragma pack(0) /* or whatever stops all packing */ >> struct read_args { >> char const *path; >> int flags; >> char pad1[4]; /* little endian, 4 byte ints, 8 byte regs */ >> mode_t mode; >> char pad2[6]; >> }; >That would be better expressed as: >> #pragma pack(8) /* quad stack alignment, pointers are quads*/ >> struct read_args { >> char const *path; >> int flags; >> mode_t mode; >> }; gcc-2.6 only supports pack(1)..pack(4) - the natural padding can't be increased. Note that it need may need to be increased to support a foreign ABI, and it isn't even natural on Pentiums (doubles should have 8 byte alignment). #pragma is unportable. My version has the advantage of requiring only 1 pragma per struct, while yours requires up to one pragma per struct member and it may still require padding. Consider alignment of 4-byte quantities on boundaries 4, 9, 16, 25, ... >> `lcall' allow users to trace into syscalls. This can be recovered from >I understand the rationale for considering the changes. I don't understand >the rationale for making them. It seems the rationale is "to compete with >NetBSD and Linux regarding speed". Is this correct? To compete in speed and elegance. >> >This was my point on the quad crap and reverting the default interfaces >> >to POSIX compliance (and double doesn't count unless you can use it >> >without a prototype in scope). >> >> if (lseek(fd, (off_t)foo, SEEK_SET) == (off_t)-1) >> perror("lseek"); >> >> works without a prototype in scope even if off_t is quad or double. >But violates POSIX (in the quad case) or the spirit of POSIX (in the >double case -- you yourself suggested that this is probably an error >in the spec). Doesn't matter. The call and check must be written something like the above so that it works independent of the type of off_t even if off_t is one of char, short, int or long. Actually if foo is a variable then it should have type off_t, and the cast of -1 is unnecessary because off_t is _signed_ arithmetic, so the statement should normally be written as if (lseek(fd, foo, SEEK_SET) == -1) perror("lseek"); >> >> Consider a 68K compiler that passes the first 2 pointer args (if any) >> >> in a0-a1 and the first 2 integer args (if any) in d0-d1 and the other >> ... >> But not stupid :-). >OK. I admit it's probably minisculely faster. Is it worth the clutter >of the xxx_OFFSET and the xxx_type and the unreadable glue routines to >get that miniscule speed "improvement"? If it is the compiler or ABI's calling convention, then you have no choice. Bruce From owner-cvs-sys Sat Oct 28 01:50:20 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA25597 for cvs-sys-outgoing; Sat, 28 Oct 1995 01:50:20 -0700 Received: (from bde@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA25543 ; Sat, 28 Oct 1995 01:50:11 -0700 Date: Sat, 28 Oct 1995 01:50:11 -0700 From: Bruce Evans Message-Id: <199510280850.BAA25543@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/kern vfs_subr.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk bde 95/10/28 01:50:10 Modified: sys/kern vfs_subr.c Log: Call vfs_unbusy() before error returns from sysctl_vnode(). This fixes PR 795. Set the size before one error return from sysctl_vnode() the same as before the other. The caller might want to know about the amount successfully read although the current caller doesn't. From owner-cvs-sys Sat Oct 28 03:11:56 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA00853 for cvs-sys-outgoing; Sat, 28 Oct 1995 03:11:56 -0700 Received: (from davidg@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA00838 ; Sat, 28 Oct 1995 03:11:46 -0700 Date: Sat, 28 Oct 1995 03:11:46 -0700 From: David Greenman Message-Id: <199510281011.DAA00838@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/kern vfs_subr.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk davidg 95/10/28 03:11:44 Branch: sys/kern RELENG_2_1_0 Modified: sys/kern vfs_subr.c Log: Brought in fix from 1.37: fix for hang caused by missing vfs_unbusy(). From owner-cvs-sys Sat Oct 28 04:26:54 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA04880 for cvs-sys-outgoing; Sat, 28 Oct 1995 04:26:54 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA04871 ; Sat, 28 Oct 1995 04:26:49 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id EAA00189; Sat, 28 Oct 1995 04:25:18 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id EAA00232; Sat, 28 Oct 1995 04:25:14 -0700 Message-Id: <199510281125.EAA00232@corbin.Root.COM> To: se@ZPR.Uni-Koeln.DE (Stefan Esser) cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, matt@lkg.dec.com Subject: Re: cvs commit: src/sys/pci if_de.c In-reply-to: Your message of "Thu, 26 Oct 95 13:42:45 BST." <199510261242.AA24313@Sysiphos> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 28 Oct 1995 04:25:09 -0700 Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk >There is a global variable for the purpose of determining >the maximum burst length. It is currently initialized to >4 longwords, but I guess having it default to 8 would be >Ok. (We reduced it to 4 because of a problem reported by >Matt Thomas with an old Saturn chip set revision). So what is the conclusion - is it safe to increase the default burst size to 8 longwords, or does this indeed cause problems for the Saturn chipset? -DG From owner-cvs-sys Sat Oct 28 05:59:34 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA10811 for cvs-sys-outgoing; Sat, 28 Oct 1995 05:59:34 -0700 Received: (from phk@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA10801 ; Sat, 28 Oct 1995 05:59:27 -0700 Date: Sat, 28 Oct 1995 05:59:27 -0700 From: Poul-Henning Kamp Message-Id: <199510281259.FAA10801@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/sys sysctl.h Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk phk 95/10/28 05:59:26 Modified: sys/kern kern_sysctl.c sys/sys sysctl.h Log: Rewamp the way we make sysctl variables to be easier to cope with. The goal is to make them "user-friendly" :-) In the end this will allow a SNMP style "getnext" function, sysctl editing in the boot-editor and/or debugger, LKMs can define sysctl vars when they get loaded, and remove them when unloaded and other interesting uses for dynamic sysctl variables. From owner-cvs-sys Sat Oct 28 06:07:34 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA11524 for cvs-sys-outgoing; Sat, 28 Oct 1995 06:07:34 -0700 Received: (from phk@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA11515 ; Sat, 28 Oct 1995 06:07:29 -0700 Date: Sat, 28 Oct 1995 06:07:29 -0700 From: Poul-Henning Kamp Message-Id: <199510281307.GAA11515@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/sys sysctl.h user.h Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk phk 95/10/28 06:07:29 Modified: sys/i386/ibcs2 ibcs2_sysi86.c sys/i386/isa npx.c sys/kern kern_sysctl.c sys/sys sysctl.h user.h Log: Sorry, the last commit screwed up for me, this is the right one (I hope!) Please refer to the previous commit message about sysctl variables. From owner-cvs-sys Sat Oct 28 08:39:46 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA21213 for cvs-sys-outgoing; Sat, 28 Oct 1995 08:39:46 -0700 Received: (from phk@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA21186 ; Sat, 28 Oct 1995 08:39:34 -0700 Date: Sat, 28 Oct 1995 08:39:34 -0700 From: Poul-Henning Kamp Message-Id: <199510281539.IAA21186@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/isa aha1542.c aha1742.c aic6360.c b004.c bt742a.c clock.c cx.c diskslice_machdep.c fd.c gpib.c if_ed.c if_el.c if_ep.c if_ix.c if_le.c if_lnc.c if_ze.c if_zp.c mcd.c scd.c si.c spigot.c tw.c wcd.c wd.c wd7000.c wt.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk phk 95/10/28 08:39:33 Modified: sys/i386/apm apm.c sys/i386/i386 trap.c sys/i386/isa aha1542.c aha1742.c aic6360.c b004.c bt742a.c clock.c cx.c diskslice_machdep.c fd.c gpib.c if_ed.c if_el.c if_ep.c if_ix.c if_le.c if_lnc.c if_ze.c if_zp.c mcd.c scd.c si.c spigot.c tw.c wcd.c wd.c wd7000.c wt.c Log: Remove unused functions and variables, make things static, and other cleanups. From owner-cvs-sys Sat Oct 28 09:58:15 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA28822 for cvs-sys-outgoing; Sat, 28 Oct 1995 09:58:15 -0700 Received: (from markm@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA28804 ; Sat, 28 Oct 1995 09:58:07 -0700 Date: Sat, 28 Oct 1995 09:58:07 -0700 From: Mark Murray Message-Id: <199510281658.JAA28804@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/isa random.c syscons.c vector.s Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk markm 95/10/28 09:58:06 Modified: sys/i386/conf files.i386 sys/i386/i386 conf.c machdep.c mem.c sys/i386/isa syscons.c vector.s Added: sys/i386/include random.h sys/i386/isa random.c Log: Theodore Ts'po's random number gernerator for Linux, ported by me. This code will only be included in your kernel if you have 'options DEVRANDOM', but that will fall away in a couple of days. Obtained from: Theodore Ts'o, Linux From owner-cvs-sys Sat Oct 28 10:27:27 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA00256 for cvs-sys-outgoing; Sat, 28 Oct 1995 10:27:27 -0700 Received: (from gibbs@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA00247 ; Sat, 28 Oct 1995 10:27:23 -0700 Date: Sat, 28 Oct 1995 10:27:23 -0700 From: "Justin T. Gibbs" Message-Id: <199510281727.KAA00247@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/scsi aic7xxx.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk gibbs 95/10/28 10:27:22 Modified: sys/i386/scsi aic7xxx.c Log: Fix incorrect bit definitions for SXFRCTL0 (typo). The affected bits aren't referenced by the driver yet, so this error shouldn't have caused any problems. Submitted by: Dan Eischen From owner-cvs-sys Sat Oct 28 22:57:57 1995 Return-Path: owner-cvs-sys Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00750 for cvs-sys-outgoing; Sat, 28 Oct 1995 22:57:57 -0700 Received: (from gibbs@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA00741 ; Sat, 28 Oct 1995 22:57:51 -0700 Date: Sat, 28 Oct 1995 22:57:51 -0700 From: "Justin T. Gibbs" Message-Id: <199510290557.WAA00741@freefall.freebsd.org> To: CVS-commiters, cvs-sys Subject: cvs commit: src/sys/i386/scsi aic7xxx.c Sender: owner-cvs-sys@FreeBSD.org Precedence: bulk gibbs 95/10/28 22:57:50 Modified: sys/dev/aic7xxx aic7xxx.seq Log: Only or in CLRCHN in SXFRCTL0. All other bits in this register are initialized by the kernel driver now. Modified: sys/i386/scsi aic7xxx.c Log: Initialize SXFRCTL0 with DFON|SPIOEN|ULTRAEN.