From: Alexander B. <le...@st...> - 2005-11-18 16:19:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/18/2005 03:57 PM, Kern Sibbald wrote: > On Friday 18 November 2005 14:25, Alexander Bergolth wrote: >>On 11/17/2005 09:16 PM, Kern Sibbald wrote: >> >>>A kludge, which I don't like much, would be to move the definition of >>>Pool into the common part of the jcr. >> >>Hmm - isn't it dangerous and error-prone anyways to have different >>definitions of JCR in lib, director daemon, file daemon and storage >>daemon and pass e.g. director jcr objects to methods in lib (and the >>other way around)? > > The library can only reference the common part of the objects. This is no > different than what C++ does with inherentance. There is no danger other than > some people may not understand the metaphore ... > >>OK, the definition of the daemon-specific attributes (data members) >>comes at the end of the class definition but I believe that it can be >>potentially dangerous if the caller (e.g. do_backup_init() in the >>director) has a different view of the object than the called function >>(e.g. edit_job_codes() in libbac). > > As I mentioned above, this is not a solution that I like, and as a > consequence, I wouldn't implement it in the code I release. If you want to > use it for your own code, I have no problem, and don't see that it can do any > harm. But that is what happens in the current code! do_backup_init() passes a jrc object (the version that has all the daemon specific members) to edit_job_codes(). But edit_job_codes() has a different view on the class than do_backup_init(). > My emphasis is going to be to try to do as much as possible with Python and to > try to reduce the use of new % variables and directives as much as possible, > so a proper solution for me is one that involves Python. I agree. >>Taken from the O'Reilly book "Linux Device Drivers": >>-------------------- snipp! -------------------- >>Another issue related to alignment is portability of data structures >>across platforms. The same data structure (as defined in the C-language >>source file) can be compiled differently on different platforms. The >>compiler arranges structure fields to be aligned according to >>conventions that differ from platform to platform. At least in theory, >>the compiler can even reorder structure fields in order to optimize >>memory usage. >>-------------------- snipp! -------------------- > > This is not an issue here as all of Bacula is recompiled on every platform. This issue may as well affect two pieces of code compiled on a single platform, due to several source files using different class definitions resulting from the #ifdef's. Imagine the following scenario: First, when libbac is compiled, the compiler only sees a limited JCR class that contains the common members. The optimizer may arrange the members in a specific pattern. Then it compiles backup.c in the director's sources. Now it sees a different JCR class, additionally containing the director specific members. Now the optimizer may arrange the members in a different way than before which will lead to problems when passing an object between those two pieces of code. While the compiler will not change the order of the members on most platforms and will most likely use the same padding to align the members, this behaviour isn't something one should rely on. >>I haven't found a similar abstract about c++ member alignment but at >>least padding is also done when aligning c++ class members. >> >>Recapitulationg I believe that it would be much more portable and a much >>cleaner coding style to have all parts of baculas code use the same >>class definitions. >>If there is a common subset of data members that is used by all daemons >>and a daemon specific part, inheritance (specialization) should be used, >>the daemon's job control records should inherit from an abstract class >>that defines the common part. > > Bacula started out as C code, and it is slowly transitioning to C++. This > transition is not easy particularly because I consider C++ one of the > lousiest languages ever written mostly due to the gross number of syntax > kludges that make it totally unreadable. However it has a few nice features > that C does not have that I am adding to Bacula. I don't want to persuade you into using inheritance, there are alternatives other than trimming structures using preprocessor macros. > If you want to propose something that is simple and does not mean changing 50% > of the code in Bacula, I am open to suggestion ... I don't want to propose major code changes, I'd only wanted to warn you that this is a possible source of errors. >>See >>http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Spec >>ialization >> >>>A much better solution, would be to enhance the Python scripting >>>interface to include all the variables you want. Most likely all except >>>%s (Since) are implemented, so it wouldn't be very hard. See >>>src/dird/pythondir.c (if I remember the name correctly), then just >>>duplicate the code necessary. Since Python can already submit a run >>>command, the rest should be rather easy and in the long run, much more >>>powerful. >> >>I planned to use the python interface anyways so I'll take a look into >>that, thanks! > > Yes, good move. That would help me a lot as I now need some "real" users so we > can gently expand the Python capabilities so that users can gets some real > control :-) I like the python interface very much as it adds a huge amount of flexibility to bacula that isn't available in any other backup tool I know. Cheers, - --leo >>>On Thursday 17 November 2005 17:16, Alexander Bergolth wrote: >>> >>>>Hi! >>>> >>>>I'd like to use the new Run-directive in the Job Resource to define a >>>>job that should be run after the main backup-job. (This job should >>>>backup the bacula database directory and is called BackupCatalog.) >>>> >>>>However, since my schedule uses daily incremental backups that go to a >>>>"PoolDaily" during the week, weekly full backups that go to "PoolWeekly" >>>>and monthly full backups that go to "PoolMonthly", I'd like to specify >>>>the BackupCatalog-Job to use the same pool as the main backup job and >>>>hence use the same tape. >>>> >>>>I'd like to use a variable like "%p" that is substituted for the pool, >>>>that the current job is using, to allow starting the BackupCatalog-job >>>>like that: >>>> >>>>Job { >>>> Name = "Samba-Homes" >>>> Schedule = "WeeklyCycle" >>>>[...] >>>> Run = "BackupCatalog level=%l since=\"%s\" storage=DLT1 pool=%p" >>>>} >>>> >>>>I've found out that "%v" is substituted by the volume-name in >>>>edit_job_codes() (in lib/util.c) but it looks like there is no variable >>>>for the pool. >>>> >>>>So I tried to add this feature using the attached patch. >>>>However, it doesn't compile because the pool attribute is only compiled >>>>into the class JCR, if DIRECTOR_DAEMON is defined. (See jcr.h) >>>>Unfortunately, when lib/util.c is compiled, DIRECTOR_DAEMON isn't >>>>defined. So jcr->pool isn't available at compile time in >>>>edit_job_codes(). However, since jcr is passed from is passed from >>>>do_backup_init() in dird/backup.c, it should be available at run-time. >>>> >>>>I'd appreciate any hint at how to solve the problem... >>>> >>>>Cheers, >>>>--leo - -- - ----------------------------------------------------------------------- Ale...@wu... Fax: +43-1-31336-906050 Zentrum fuer Informatikdienste - Wirtschaftsuniversitaet Wien - Austria -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDff8YsYaksEkoAQMRAkxHAJ4yG0HcMg6DI8Y6CatWrzUOELvFWwCeN5KQ 6WTV304XNL7x/cswjiCBGwc= =d7Iv -----END PGP SIGNATURE----- |