[DRBD-user] using drbd in a monolithic kernel?

[Lars Ellenberg]

/ 2004-03-23 09:53:33 +0100
\ Philipp Reisner:
> Am Freitag, 19. März 2004 17:32 schrieb Kees Cook:
> > On Fri, Mar 19, 2004 at 10:03:55AM +0100, Philipp Reisner wrote:
> > > are you going to maintain these patches ? -- At least for now ?
> >
> > I'm happy to maintain the 2nd if the first can be put into CVS.  I tried
> > to make sure it wouldn't break the existing build process.  It makes
> > putting it into the kernel tree muuuch easier.  ;)
> >
> > Is there anything bad about the first patch?  I'm happy to clean it up as
> > you see fit.
> 
> Hi Kees,
> 
> I have to admit that I did not realized in the first run that the first 
> patch was meant to be applied, and that it does not conflict with the
> module build. I realized that by now and I am up to applying it. 
> 
> But:
> 
> I am thinking about making the include directory a sub-directory
> of drbd which would lead to:
> 
> 
> drbd/drbd_*.c
> drbd/[include/]linux/drbd.h
> drbd/[include/]linux/drbd_conf.h
> 
> * As far as I understand the woes of the packet maintainers, they would
>   like to see all the sourced for building the modules in one tree.
> 
> * And a symlink in the root directory of the distribution tarball, so
>   that people see the drbd_conf.h in the uppermost directory.
> 
> * Actually the [include/] part in the path is not necessary, so I
>   am thinking about omitting it.
> 
> Lars, David, Philipp: Any oppinions on how the sources should be layed out,
>   from the viewpoint of a package maintainer ?

We could as well "split" it into a kernel patch, and the user level tools.

or,
patch_kernel: could be a special makefile target, which symlinks the
the drbd-kernel-part into drivers/block/drbd, and patches the
relevant entries into the kernel build system.

For the headers: as long as no one but drbd itself needs to know about
its headers, they can remain private headers, and stay in the drbd
subdirectory, whether that is in the kernel tree or not.
Currently only our own userland tools use the drbd{,_conf}.h .

But yes, if we move things around, we may as well do it right *now*.
drbd_conf.h should then (automagically due to kernel build) become
/usr/src/linux/include/config/drbd.h, and (un)define CONFIG_DRBD,
CONFIG_DRBD_* ...

	Lars Ellenberg