04 Dec, 2008

1 commit

  • We lack compat ioctl support through most of the ATM code. This patch
    deals with most of it, and I can now at least use BR2684 and PPPoATM
    with 32-bit userspace.

    I haven't added a .compat_ioctl method to struct atm_ioctl, because
    AFAICT none of the current users need any conversion -- so we can just
    call the ->ioctl() method in every case. I looked at br2684, clip, lec,
    mpc, pppoatm and atmtcp.

    In svc_compat_ioctl() the only mangling which is needed is to change
    COMPAT_ATM_ADDPARTY to ATM_ADDPARTY. Although it's defined as
    _IOW('a', ATMIOC_SPECIAL+4,struct atm_iobuf)
    it doesn't actually _take_ a struct atm_iobuf as an argument -- it takes
    a struct sockaddr_atmsvc, which _is_ the same between 32-bit and 64-bit
    code, so doesn't need conversion.

    Almost all of vcc_ioctl() would have been identical, so I converted that
    into a core do_vcc_ioctl() function with an 'int compat' argument.

    I've done the same with atm_dev_ioctl(), where there _are_ a few
    differences, but still it's relatively contained and there would
    otherwise have been a lot of duplication.

    I haven't done any of the actual device-specific ioctls, although I've
    added a compat_ioctl method to struct atmdev_ops.

    Signed-off-by: David Woodhouse
    Signed-off-by: David S. Miller

    David Woodhouse
     

15 May, 2008

1 commit

  • The atm_tcp.h uses types from linux/atm.h, but does not include it.
    It should also use the standard __u## types from linux/types.h rather
    than the uint##_t types since the former can be found with the kernel
    already.

    Same goes for linux/atm.h. The linux/socket.h include there also gets
    dropped as atm.h does not actually use anything from socket.h.

    Signed-off-by: Mike Frysinger
    Signed-off-by: Andrew Morton
    Signed-off-by: David S. Miller

    Mike Frysinger
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds