From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <93f71afb320e8cd61cd2ff3f9f08ebbe@quintile.net> From: "Steve Simon" Date: Fri, 6 Jul 2007 15:43:34 +0100 To: 9fans@cse.psu.edu Subject: Re: [9fans] implementing 9p read In-Reply-To: <468D8253.9030400@wmipf.in-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 91e5ed92-ead2-11e9-9d60-3106f5b1d025 > This probably also means that Read returns in > most cases less bytes than requested, just as much as needed for the > current line up to \n. The server likely has to keep some information > like the next read-offset expected, and the next line number, so that it > can check whether the next read-request actually asks for the next line > -- if it doesn't ignore seek/offsets at all, which also seems practicable. You cannot do this, the usual idiom is that if read returns less than the app expected this is treated as EOF. in my library the low level function generates line at a time data, the library then performs multiple reads to satisfy the apps read request filling its buffer and rembembering the partial line for the next read request. > I suppose this is adequate for control files waiting for commands. One > can leave the fd open, and send one line after the other as needed. I don't generally find this is nescessary, the fileserver/device driver holds internal state so multiple writes mearly modify this state, thusly: echo 'cts=1' > /dev/uart/ctl echo 'baud=115200' > /dev/uart/ctl We get a real win using the everything is a file idea in embedded as most of our products contain multiple PCBs and each PCB has a CPU (to load its xilinxes if nothing else). Given the remote file protocol running over a a couple of wires (the link layer distantly related to datakit) we can monitor any cpu from any other cpu and upgrade all flash files from the cpu that has ethernet. Its a shame that we didn't have the guts and skill to make it real plan9 from the begining - hindsignt is a wonderful thing. -Steve