From mint-bounce@lists.fishpool.fi Fri Oct 29 13:38:47 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Date: Fri, 29 Oct 2004 13:37:19 +0200 (CEST) From: Frank Naumann X-X-Sender: fnaumann@muecke.local To: mint@fishpool.com Subject: Re: [MiNT] Fpoll() in GEM programs In-Reply-To: Message-ID: <20041029123519.O20936@muecke.local> References: <417CD550.80306@atari.org> <20041027172635.1489.qmail@mailcz.in.systinet.com> <417FE0B2.5010403@utbm.fr> <200410280115.29861.h.robbers@chello.nl> <20041028084227.K3028@muecke.local> <200410 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scan-Signature: 31da23c7ad8723c3eceff3a847967b8d X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: fnaumann@cs.uni-magdeburg.de Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=3.8 tests=BAYES_00 X-Spam-Level: Hello! > Is it possible for the AES to create a file descriptor, and set the current > process id as the owner of this file descriptor ? The kernel don't manage the resources in this way. Every process have it's own, private file descriptor table. But how does a process know what the AES provide this feature and how does the process know which is the right descriptor? > I never talked about pipe. I only talked about the generic "file descriptor" > term, because it cover lot of things. You know that there must be some code behind this file descriptor? > Ok... i'll once more try to argument on a subject i don't know very well... > BTW, if i correctly understand, we cannot create a file descriptor. We can > create a file and the function returns a filedescriptor. We can create a pipe > and the function returns a fd. We can create a socket and the function > returns a file descriptor... a "file description" is a generic handle that > may hide a lot of very different things, and i'm not sure that pipe is the > good type for our need. So you need to introduce a new type. > There's nothing magic. We can read/write stuff to this file descriptor (if > needed), but only AES functions has to do it. There are lot of other things you are probably not aware yet. A file descriptor is more than just a read/write/select interacting resource: - A file descriptor is an elementar resource a process can create/modify/destroy - A file descriptor is inherited by child processes - A file descriptor is duplicateable - A file descriptor is manipulable in various ways: - setting/getting attributes - modifying behaviour - A file descriptor support fstat, fchown, fchmod and such things > exceptfds > This set is watched for exceptions or errors on any of the file descriptors. > However, that is actually just a rumor. How you use exceptfds is to watch for > Out of Bounds (OOB) data. OOB data is data sent on a socket using the MSG_OOB > flag, and hence exceptfds only really applies to sockets(...) > " > > This feature may be used, no ? So you want to use the error exception event to notify about regular AES events? Funny ... > The AES writes stuff to itself, and read stuff > from itself, using OOB data; i don't see any magical thing here. I don't understand. Until know you said the AES inform the process about new AES events through a file descriptor. Regards, Frank -- ATARI FALCON 060 // MILAN 060 ----------------------------------------- http://www.cs.uni-magdeburg.de/~fnaumann/ e-Mail: fnaumann@freemint.de