Alexander Viro wrote:
>
> On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> > Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> > either sync_dev() or fsync_dev(). What do you think about pulling that
> > into the same function? Actually, that's what I've done in namespace
> > patch (name being invalidate_dev(), BTW ;-) The only problem I see
> > here is the argument telling whether we want sync or fsync (or nothing).
> > OTOH, I seriously suspect that we ought replace all sync_dev() cases
> > with fsync_dev() anyway... Your opinion?
> > Al
>
> PS: last time I've separated that part of patch was a couple months
> ago. See if something similar to the variant below would be OK with
> you (I'll rediff it):
I think in the context you are inventig the proposed function,
the drivers has allways an inode at hand. And contrary to what Linus
says, drivers not just know about the devices they handle, they
know about the data they should get - at least in the context
of block devices. And then you could as well pass the inode, which
is already containing a refference to the corresponding sb and
save the whole get_super linear array lookup 8-). I think
the less kdev_t the better! It's overused already anyway, like
for example in the whole SCSI code, where the functions in reality only
want to pass the minor number to differentiate they behaviour...
If you are gogin to flag the behaviour of the function,
then please use a bitpattern of well definded flags as a parameter,
in a similiar way like it's done for example in many GUI libraries
(GTK, Motif and so on). This would make it far more readabel.
-- just my two euro-cent's...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:20 EST