[lkml]   [2000]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Updated bfs to use new mark_buffers_dirty interface

I think it is worth it to clarify this even if you already understood it
yourself - other readers of linux-kernel may find it useful (and those who
find it too obvious will forgive me).

The concept of Linux subsystem maintainer doesn't mean that _any_ changes
to his subsystem should go through him/her. For example, I maintain BFS
filesystem but Linux VFS has undergone a huge amount of changes (well, a
rewrite, or even several rewrites) by Al Viro who is always kind enough to
make sure his changes don't break any filesystems. So, when he changes VFS
he simply updates BFS (and all other filesystems) without bothering me
(and all other maintainers) about it. Of course, maintainers ought to
monitor his changes (and they do) and voice their opinions if they believe
he breaks anything (he never does :).

So, this mark_buffer_dirty() change is a good example of the situation
where you should _not_ bother maintainers but produce a big patch and send
to Linus (if 100% confident) or to linux-kernel (if 99% confident).


On Mon, 4 Sep 2000, Tigran Aivazian wrote:

> On Mon, 4 Sep 2000, Rasmus Andersen wrote:
> > Hi.
> >
> > I have changed the interface to mark_buffer_dirty (as per your
> > suggestion to Arnaldo Carvalho de Melo). This impacts bfs as per
> > the following patch.
> >
> Rasmus, thanks of course, but this idea _only_ makes sense if you produce
> a big patch that includes _all_ filesystems and the actual VFS interface
> to them. Doing individual filesystems, in this case, is no use at all -
> your patches cannot be applied gradually.
> To be more blatant, the patch you sent me "breaks" bfs because it won't
> compile anymore... see what I am saying?
> Regards,
> Tigran

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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