lkml.org 
[lkml]   [1998]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.1.118 Tons of oopes
    Gregory P. Smith writes:
    >
    > > > > Before I get into the part about the flames, I have a suggestion: how
    > > > > about we start using the GCC intialiser extensions? In other words, if
    > > > > I have a "xyz" driver, I do this:
    > > > >=20
    > > > > struct file_operations xyz_fops =3D {
    > > > > open:xyz_open,
    > > > > read:xyz_read,
    > > > > write:xyz_write,
    > > > > };
    > > > >=20
    > ...
    > > >
    > > > IMNSHO, the whole usage of NULL silly. Is there a good reason why
    > > > we're not simply a pointer pointing to a routine implementing the
    > > > default action? (Does nothing if empty?) That way we wouldn't have
    > > > to have a null pointer check on every call...
    > >
    > > Yes, I can see the benefit of avoiding the NULL check. It would be
    > > nice to be able to do this. However, that would then require every
    > > driver to be updated on every addition of a new VFS method.
    > ...
    > > However, if there was some compiler trickery we could employ such that
    > > a VFS change doesn't require source code to be touched, it would be a
    > > good idea. Being able to strip those method existence tests would make
    > > code a bit more readable and would also save a few cycles. But I don't
    > > see how to do it without making drivers not distributed with the
    > > kernel much harder to maintain.
    >
    > Doing some brainstorming:
    >
    > How about defining a varargs function that takes as parameters
    > pointers to the VFS methods in a permanently defined order.
    > This way future methods could be added to the end and for drivers not
    > using them the function could fill them in with the default action
    > pointer. The drawback is that this would need to be done in an
    > initialization function.

    No, this is exactly what Linus doesn't want, as I now understand
    it. The scheme you proposed has the same effect as the one I proposed,
    which is to effectively allow driver writers to ignore new methods in
    the VFS.
    You're probably suffering from the same misconception that I was,
    namely that Linus wanted to preserve compatibility. What he wants to
    do is highlight to people that the new flush() method exists and
    people should consider coding up an implementation where needed. He
    feels that any scheme which allows a driver to ignore the new method
    results in people not paying attention to the introduction of a new
    method, which he feels leads to a maintenance problem. He sees the
    best way of forcing people to consider the new flush() method is to
    break all drivers and filesystems.
    Unless I'm still mistaken, that is his position.

    Unsurprisingly, I don't agree with such forceful measures: I'd rather
    just announce the new method and tell people what it does and why some
    drivers/filesystems may need to implement it. But I'm not making the
    decisions.

    Regards,

    Richard....

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:2.299 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site