[lkml]   [2001]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [V4L] Re: [RFC] alternative kernel multimedia API
    > > drivers to ask for specific minor numbers (so you can give your devices
    > > fixed minor numbers using insmod options). And this has _NOTHING_ to do
    > > with the API visible to the applications.
    > It has to do with the API visible to the driver.

    Yes. Why do you mix the two? These are completely separate issues.

    > > Such clashes shouldn't happen as v4l has ioctl number ranges for driver
    > > private stuff which can be used for such tests and shouldn't cause
    > > clashes with new, official ioctls.
    > I did not know that - thanks. Where do I find notes on this ?

    BASE_VIDIOCPRIVATE is defined in videodev.h and used by various drivers
    in drivers/media/video

    > > Beside that I don't see why breaking applications is a problem for
    > > _experimental_ interfaces. On the one hand you want to have the
    > It is a problem because I want as many people as possible to try them.
    > This is the only way to work out installation dependent bugs. There is a
    > lot of variety out there: Redhat, Mandrake, Slackware, Suse, ix86,
    > PowerPC, Alpha, Sparc.. Each is a little different.

    And how installation issues are related to API design / testing?

    > > flexibility to change interfaces easily to test them, on the other hand
    > > you care alot about compatibility and stuff. You can't get both, I
    > > don't see a way to do that without making either the drivers or the
    > > applications (or both) very complex.
    > Now here you are wrong. C have not changed in a while and you can still
    > write any programs in it ;) As for complexity.. I don't mind 10000 line
    > file if it is backed up by good algorithm. The good news is that with this
    > approach we separate interface stuff from driver dependent stuff - and,
    > hence, the most complex part can be easily tested.

    I doubt this. IMHO the complex part isn't the read/write interface and
    the string parsing (I'd expect this can easily separated out into some
    kind of library / kernel module / whatever). The complex part is to
    keep the backward compatibility while changing/improving the interfaces
    (which is one of your goals with the new approach, right?), and I don't
    see a way to handle that in generic, driver-independant code ...


    Netscape is unable to locate the server localhost:8000.
    Please check the server name and try again.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:18    [W:0.041 / U:15.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site