Also 16 events will NOT be enough when you are talking mouse, keyboard, and
joystick combined so the problem is even larger.
On Fri, 26 Jun 1998, Allanah Myles wrote:
> Date: Fri, 26 Jun 1998 02:44:31 -0400
> From: Allanah Myles <dossy@panoptic.com>
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: uniform input device packets?
>
> On 1998.06.25, Albert D. Cahalan <acahalan@cs.uml.edu> wrote:
> > Oh, the bitfields are insane. This is local kernel --> app data
> > transfer, caused by a human. It's not networking over a modem.
> > It is better to just make everything 32-bit. If performance is
> > really an issue, think about all the bitshifting you can avoid.
>
> Well, let me put forth the question - what's more expensive
> computationally, a bitshift or bitwise-and, or a 4-byte
> read/memcopy?
>
> I'd rather read 2 bytes and mangle their bits around rather than
> having to, say, read 16 bytes to obtain the same amount of data.
> Unless, you can tell me that it's faster to just read the 16
> bytes.
>
> Also, since we'll need to buffer these events in memory until
> they're drained from the queue - having to queue 16 bytes per
> event is *SO* wasteful of system resources (especially with
> a large number of devices in this system). Say each device
> queue is 16-events large (I *believe* this is what the PC
> keyboard BIOS driver does, somewhere around 16 events). At
> 16-bytes an event, you're allocating a whole 256 bytes to
> this queue. At 3 or even 4 bytes per event, you're only
> using like 64 bytes per queue. Sounds like small numbers,
> but depending on how large each event is, it adds up.
>
> -Dossy
>
> --
> URL: http://www.panoptic.com/~dossy -< BORK BORK! >- E-MAIL: dossy@panoptic.com
> Now I'm who I want to be, where I want to be, doing what I've always said I
> would and yet I feel I haven't won at all... (Aug 9, 95: Goodbye, JG.)
> "You should change your .sig; not that the world revolves around me." -s. sadie
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNZPE2D7msCGEppcbAQHt2Qf+NUUp1ganTllhGXaQohOlQgtCTDQEa6rA
gY0or/m6d4YiXDt8JdkjGJuJfV0z+JFZRxQNvqVaDPWHS7CmjIb8c14YoAmmKCbH
nRG/yEY3Rg5qH8pjdx1krRqppKJ9hcXIjFD8VYMTyB36SBlJo43P64a0pK13YoJq
BHTJ6cBPNjqlI9iz9ETeXdyb+BhMkoHn10GZkBrk5w/84paNuVTybOWvB8xozrKz
DP/6NIs8j7/TiSzrf7S4wJCR8AhCxHeaAA0fEOuELGuek4P9bc9NN9JmtrBhqhZA
UbfMgpxIPA0cafzGCyxopgcQVJtkhCg7M3NjldGovpdkNO7HOCD42Q==
=IyY3
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu