At 11:09 PM +0100 4/23/01, Matt wrote:
>| struct instruction_t {
>| __s16 code;
>| __s16 rxlen;
>| __s16 *rxbuf;
>| __s16 txlen;
>| __s16 *txbuf;
>| };
>
>So far, I now know I can grab stuff across the user <-> kernel divide as I
>planned. The only problem I'm left with, w
Matt mentioned the following:
| struct instruction_t {
| __s16 code;
| __s16 rxlen;
| __s16 *rxbuf;
| __s16 txlen;
| __s16 *txbuf;
| };
So far, I now know I can grab stuff across the user <-> kernel divide as I
planned. The only problem I'm left with, which was kind
On Mon, Apr 23, 2001 at 08:58:54PM +0100, Matt wrote:
> Matt aka Doofus festures mentioned the following:
>
> | struct instruction_t local;
> | __s16 *temp;
> |
> | copy_from_user( &local, ( struct instruction_t * ) arg, sizeof( struct
>instruction_t ) );
> | temp = kmalloc( sizeof( __s16 ) * l
On 23 Apr 2001, Mathieu Chouquet-Stringer wrote:
> <[EMAIL PROTECTED]> writes:
>
> > On Mon, 23 Apr 2001, Ingo Oeser wrote:
> >
> > > On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote:
> > > > I'm writing a char device driver for a dsp card that drives a motion
> > > > platform.
> > >
> > > Ca
<[EMAIL PROTECTED]> writes:
> On Mon, 23 Apr 2001, Ingo Oeser wrote:
>
> > On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote:
> > > I'm writing a char device driver for a dsp card that drives a motion
> > > platform.
> >
> > Can you elaborate on the dsp card? Is it freely programmable? I'm
>
rui.sousa mentioned the following:
| On Mon, 23 Apr 2001, Ingo Oeser wrote:
|
| > Can you elaborate on the dsp card? Is it freely programmable? I'm
| > working on a project to support this kind of stuff via a
| > dedicated subsystem for Linux.
|
| Very interesting... The emu10k1 driver (SBLive!
Ingo Oeser mentioned the following:
| On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote:
| > I'm writing a char device driver for a dsp card that drives a motion
| > platform.
|
| Can you elaborate on the dsp card? Is it freely programmable? I'm
| working on a project to support this kind of
On Mon, 23 Apr 2001, Ingo Oeser wrote:
> On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote:
> > I'm writing a char device driver for a dsp card that drives a motion
> > platform.
>
> Can you elaborate on the dsp card? Is it freely programmable? I'm
> working on a project to support this kind o
Matt aka Doofus festures mentioned the following:
| struct instruction_t local;
| __s16 *temp;
|
| copy_from_user( &local, ( struct instruction_t * ) arg, sizeof( struct instruction_t
|) );
| temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL );
| copy_from_user( temp, arg, sizeof( __s16
On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote:
> I'm writing a char device driver for a dsp card that drives a motion
> platform.
Can you elaborate on the dsp card? Is it freely programmable? I'm
working on a project to support this kind of stuff via a
dedicated subsystem for Linux.
The p
> And there is very low chance that kmalloc() for
> anything bigger than 4KB will succeed. You should either use
> vmalloc unconditionally, or at least as fallback.
The phrase 'very low chance' is inaccurate.
How do you think NFS works with -rsize, -wsize > 4096?
kmalloc() uses get_free_pages()
On 23 Apr 01 at 17:06, Matt wrote:
> struct instruction_t {
> __s16 code;
> __s16 rxlen;
> __s16 *rxbuf;
> __s16 txlen;
> __s16 *txbuf;
> };
You should reorder fields, starting with largest fields and going down
to smaller ones. That ways you'll not have troubles with alignmen
12 matches
Mail list logo
