RE: [MiNT] AES in kernel

[Noah silva <nsilva@sparcy.atariuniverse.com>]

On Tue, 9 Jan 2001 Jo-Even.Skarstein@vital.no wrote:

> > -----Original Message-----
> > From:	Vincent Manuel Barrilliot [SMTP:vbarr@cme.nist.gov]
> > Sent:	Tuesday, January 09, 2001 4:20 PM
> > To:	mint@fishpool.com
> > Subject:	Re: [MiNT] AES in kernel
> > 
> > As fas as the GEM is concerned, input devices managements is up to the
> > VDI, 
> > which the AES should use to get its events and dispatch them.
> > 
> Why must it be so? If /dev/mouse worked properly, *and* it was possible for
> other kernel modules to access /dev/mouse and /dev/keyboard without causing
> a context switch, the "AES in kernel" design should work just fine. And the
> VDI could read these devices as well.
> 
> > An AES in the kernel pauses the problem of being able to Fselect an
> > VDIevent 
> > 
> But why use a VDIevent device? If the AES doesn't use the VDI for it's
> input, there's no need for this.
> 
> > device, and also the system can be dragged down by a crashed AES. But it
> > solves 
> > 
> The system can also be dragged down by any other crashed device driver or
> filesystem. Most of the AES would run outside the kernel anyway, so would
> the VDI.

And, almost any program can be perfected to basically be bug free.  It's
not as if the AES must be a huge program.  Add to it pointer checking and
sanity checks as well, and you would get greater stability at the expense
of a few percent performance drop.
The AES is something that should be pretty much bulletproof anyhow, as if
it crashes, you will lose control of all of your AES programs.  (though it
would be interesting to see a way to restart the AES and regain control of
the programs, but I have yet to see this).


> 
> > the problem of synchronisation, 32-fd limit and improves performance.
> > 
> Indeed.
> 
> Jo Even Skarstein
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> 
> This email with attachments is solely for the use of the individual or 
> entity to whom it is addressed. Please also be aware that 
> Vital Insurance/DnB Group cannot accept any payment orders or other 
> legally binding correspondance with customers as a part of an email. 
> 
> This email message has been virus checked by the virus programs used 
> in the Vital Insurance/DnB Group.
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> 
>