Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> Hi Christopher , > > Thank you very much! I think making the programs more self contained > is the right way.. . > >> This patch doesn't completely address "Child process does not terminate" >> because drbdadm calls drbdsetup. Besides this problem the return code >> of drbdsetup is discarded by drbdadm which would be useful. Is there a >> reason these two programs are separate? > > The basic idea is to have more smaller tools (drbdadm, drbdsetup, drbdmeta) > and each does the job it is designed for... > > Of course in the course of the development a few things went wrong, like > drbdadm discarding drbdsetup return values... etc. But I rather think > that this is an implementation bug that should be fixed, rather than > making a big program our of the three small ones. (each by itself complex > enough. Agreed, I wasn't trying to make drbdadm into a honking beast. :) I would prefer things to be the UNIX way as well, small defined tools that have one job and do it well. > * There is a plan to have multiple version of drbdsetup around, e.g. > each carrying the version number of the IOCTL interface in it's name. > drbdsetsetup_api_80 ... and a symlink > > * drbdadm is our way of storing DRBD's configuration in a file. E.g. > The http://www.linuxha.net stuff completely ignores drbdadm and > does everything by calling drbdsetup. Would it better to turn drbdsetup into a shared library and write the other tools around it, i.e. drbdadm, drbdmeta. Ultimately, I'm trying to fix the issue we're seeing. We've switched to using drbdsetup as well. Maybe the correct solution is to figure out why calling drbdsetup from drbdadm is causing the problem. > > Christopher, > currently I am running out of time. I strongly consider to apply your > patch to SVN, but it will probably happen in the week from 22nd of May. > Before committing it I want to read it, understand it and test it a bit... > Thanks! I'm in no rush. Christopher