From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] Ephase question. From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 13 Aug 2002 13:28:47 -0400 Topicbox-Message-UUID: dc7e8074-eaca-11e9-9e20-41e7f4b1d025 > and, out of curiosity, were there ever syscalls for > slots 48 and 49? if so, what'd they do? I think the gap is historical. We split the 9P2000 kernel and libraries from the main sources and added all the new 9P2000 code in a separate tree. At some point while the trees were split, we added pread and pwrite to both systems. In the 9P2000 system, they were 37 and 38 (previously occupied by read9p and write9p). The calls got added to the 9P1 systems some time later, because they were too convenient not to have, and I think 50 and 51 got used just to be out of the way as a temporary slot until the 9P2000 kernels got installed. (We couldn't replace read9p and write9p in the 9P1 system, so we needed new numbers. At the time, the biggest 9P1 syscall number was seek at 39, while the 9P2000 syscalls were slowly eating the 40s. I think 50 was just a safe bet.) One compatibility measure taken in the 9P2000 kernels is that all the old system calls are emulated, so that old binaries (at least those that don't read directories) continue to work. This implies that we had to allow 50 and 51 as pread/pwrite, so we just changed the numbers rather than have two for each. Hence the gap. There was in fact a summer student project using 40 and 41, but they got recycled for 9P2000 calls. Pedantically, Russ