Message queue API enhancement needed for libisofs

[scdbackup]

This is a long term trap that should be solved soon.

Problem: When new severities are introduced then the producer of such messages has to provide translation functions from severity to text and vice versa. libburn does, libisofs does not. For now libisoburn uses the translation functions of libburn and tunnels messages through the libburn message queue which it generated from libisofs error replies.

But iso_error_get_severity() can theoretically issue severities which libburn does not know yet. So it can neither be translated nor submitted to the libburn message queue.

So it is necessary that libisofs can take care by itself for the severities which it issued as messages or as error return codes.

The libburn message API which is used by libisoburn for now:

/** Submit a message to the libburn queueing system. It will be queued or
    printed as if it was generated by libburn itself.
    @param error_code The unique error code of your message.
                      Submit 0 if you do not have reserved error codes within
                      the libburnia project.
    @param msg_text   Not more than BURN_MSGS_MESSAGE_LEN characters of
                      message text.
    @param os_errno   Eventual errno related to the message. Submit 0 if
                      the message is not related to a operating system error.
    @param severity   One of "ABORT", "FATAL", "FAILURE", "SORRY", "WARNING",
                      "HINT", "NOTE", "UPDATE", "DEBUG". Defaults to "FATAL".
    @param d          An eventual drive to which the message shall be related.
                      Submit NULL if the message is not specific to a
                      particular drive object.
    @return           1 if message was delivered, <=0 if failure
*/
int burn_msgs_submit(int error_code, char msg_text[], int os_errno,
                     char severity[], struct burn_drive *d);

** Convert a severity name into a severity number, which gives the severity
    rank of the name.
    @param severity_name A name as with burn_msgs_submit(), e.g. "SORRY".
    @param severity_number The rank number: the higher, the more severe.
    @param flag Bitfield for control purposes (unused yet, submit 0)
    @return >0 success, <=0 failure 
*/
int burn_text_to_sev(char *severity_name, int *severity_number, int flag);

/** Convert a severity number into a severity name
    @param severity_number The rank number: the higher, the more severe.
    @param severity_name A name as with burn_msgs_submit(), e.g. "SORRY".
    @param flag Bitfield for control purposes (unused yet, submit 0)
*/
int burn_sev_to_text(int severity_number, char **severity_name, int flag);

These functions quite directly forward the libdax_msgs.[ch] functions

int libdax_msgs_submit(struct libdax_msgs *m, int origin, int error_code,
                       int severity, int priority, char *msg_text,
                       int os_errno, int flag);

int libdax_msgs__text_to_sev(char *severity_name, int *severity,
                             int flag);

int libdax_msgs__sev_to_text(int severity, char **severity_name,
                             int flag);

so implementation is not much work.

The current remedy in libburn and xorriso is to know in the app the newest pairs of severity text and code. Although these pairs are not inner secrets of the message system, this is not a clean solution.

[vreixo]

But iso_error_get_severity() can theoretically issue severities which libburn does not know yet.

mmm, it shouldn't, as libiso_msgs is copied from libdax_msgs.

[scdbackup]

The current scenario is as follows:

xorriso+libisoburn depends on libisofs-0.6.2 which knows severity MISHAP, and on libburn-0.4.2 which does not know MISHAP. libburn-0.4.3 of course knows what libisofs knows.

The problem will be solved in xoriso-standalone as soon as it officially endorses libburn-0.4.4 which will happen when libburn-0.4.4 gets released.

In dynamically linked xorriso-0.1.0 it may become arbitrarily bad. This binary will link with future libisofs which might issue severities unknown to xorriso and unknown to libburn. Then my current remedy will fail to work.

We need both libraries taking care of their own message system. The tunnel botch in libisoburn must be ended soon. It is not a viable way to let libburn take care for libisofs messages.

Above three API functions will allow libisoburn to let libisofs care for its own messages, which it will of course understand as far as needed. (libisofs does not need to have a burn_drive as parameter, of course. But it should forward the service of the three libdax_msgs calls.)

Currently we have a self developing ABI bug. It needs to be stopped.

[vreixo]

This problem was caused because we release libisofs with a unreleased libburn feature. This shouldn't happen anymore. In my opinion both libraries should be released together from now on.

[scdbackup]

Preliminary bundle of implementation (untested)

[scdbackup]

If we couple all libraries together, why have three distinct libraries at all ?

How long will it last until by incident all three libs are in the state to be released ? What shall i do while i wait for other libraries to get ready ?

I need libisofs features to which libisoburn can link dynamically. This is only possible in form of a stable release.

No stable releases = no progress of libisoburn+xorriso.

Hampering of stable releases = hampering of progress.

BTW: I still do not get mail notifications from this ticket. Please notify me if you post comments.

[vreixo]

No stable releases = no progress of libisoburn+xorriso.

I recommend you to base libisoburn/xorriso development in libisofs development version. This is what we have done until now and it is more or less a good way to work. Just be in contact with me for what new features are supposed to be stable and what is just experimentaion stuff. That should be also the role of mainline. My branch is development / experimental branch. Mainline is developmnet but quite stable branch. You should develop against features commited to mainline, even if they are not released yet.

[scdbackup]

Second edition of the changes

[scdbackup]

I cannot develop towards an unstable feature set if i have to serve .so linking.

[vreixo]

bundle_A80222_2 merged and pushed to my branch. Some little notes:

• I have remove the flag parameter. It is not used and I really doubt it is useful in those functions, and given no libisofs function has that...
• I have accepted your proposal of a iso_msgs_submit() function, but I seriously doubt it is a good idea to let application submit messages as if it were libisofs.

I cannot develop towards an unstable feature set if i have to serve .so linking.

You cannot release! But you can develop... If not libisoburn/xorriso needs to be under libisofs development, and that is not a good idea, in my opinion. xorriso is a good app to test and get real use cases for libisofs.

[scdbackup]

I am still testing that patch.

And the flag has a reason. You will see tomorrow or in a year or never. But it has a reason.

[scdbackup]

Not that i would understand with what version bzr compared with my 3rd edition of the changes

[scdbackup]

The changes are still not complete.

Nevertheless you should have a look at the third patch http://libburnia-project.org/attachment/ticket/125/bundle_A80222_3 because obviously it is not based on what i see on the web interface of  https://code.launchpad.net/~metalpain2002/libisofs/vreixoml

Mess-up complete already ?

I used this command to produce the bundle after i saw the transition to 0.6.3 in the web interface.

bzr bundle http://bazaar.launchpad.net/~metalpain2002/libisofs/vreixoml

If i understand the bundle right, then it saw 0.6.2 in the remote version.

[vreixo]

I am still testing that patch.

ups, please report that it is a experimental change in that case... anyway I think it is ok

And the flag has a reason. You will see tomorrow or in a year or never. But it has a reason.

what reason? for me it is clear that these two function wont never need it... if you have strong reasons against my opinion, please expose them. I've no problem to add the flag again. But given no libisofs function has the flag yet (sure a good resource for guarantee api compatibility in some cases), I really don't think these are good candidates for flag...

The changes are still not complete.

Not a problem, I'm commiting to a development branch...

If i understand the bundle right, then it saw 0.6.2 in the remote version.

No, the remote version is 0.6.3, it is your local version who was 0.6.2. Bundles reflect also remote changes. Don't worry about it. I also don't understand them too much... They work. bzr is very good managing merges. That is enought for me.

[vreixo]

bundle_A80222_3 accepted and commited. Pushed to my development branch (rev 360). You still need to convince myself for flag param in those API functions, all other changes are commited, including the flag in internal function (it is not needed anyway, we can add it later if we really need it, it is not API, but...).

[scdbackup]

The flag parameter is an investment into futire API stability.

Its justification is visible only in hindsight after it was helpful. A certain amount of my flags stay useless, but some become bright stars because they helped solving problems which were unknown when those flahs were introduced.

It is the poer of reserved bits. Hard to explain. Easy to experience. Some day.

---

Other point: our libisofs versions are differing at least by the flags. But the bzr bundle is *empty* now.

How would i submit further changes under such circumstances.

(Actually, i still did not end testing)

[scdbackup]

Differences which bzr does not show me

[scdbackup]

Errata:

future instead of "futire", flags instead of "flahs", power instead of "poer"

[scdbackup]

A few minutes ago, the previously unused flag of

int Xorriso_option_print_size(struct XorrisO *xorriso, int flag)

proved its value. changeset 1572

This was not a forced demonstration but just a usual incident when working on my todo list. Such bit adding happens every one or two weeks. Somewhere in the code. (Do not ask me now where the next one will happen. Ask me afterwards.)

[scdbackup]

http://libburnia-project.org/changeset/1573

[vreixo]

A few minutes ago, the previously unused flag of proved its value.

Yes, flags are useful is some cases. But the two int to string and string to int functions are not the case.

[scdbackup]

The remedy implemented now is this:

libisoburn-0.1.0.pl01.tar.gz will replace libisoburn-0.1.0.tar.gz.

This version will demand exactly libisofs-0.6.2 or refuse to start:

$ xorriso/xorriso -version
xorriso 0.1.0 : RockRidge filesystem manipulator, libburnia project.

Starting up libraries ...
xorriso : FATAL : Cannot initialize libraries. Reason given:
libisofs-0.6.3 - MISMATCH -, due to a bug in this libisoburn version: need exactly libisofs-0.6.2 ,
libburn-0.4.3 ok, for libisoburn-0.1.0
$

The patch can lead to somewhat skurrile version messages if libisoburn was compiled with newer headers and then gets plugged to its matching libisofs version:

libisofs   in use :  0.6.2  (min. 0.6.3)

But it works in that situation.

I decided against repairing that ornamental problem. This decision shall make the patch more safe. Ugly it is anyway.

[deewang]

Thanks for a resourceful content. this is what i have been looking for so long. I don't get the idea why they start these kind of trial when the criminal are old. Perhaps this more personal form of accountability will deter future actors where the fear of international condemnation has not. Ed Hardy stores are located in many locations internationally including the Americas, Europe and Asia.

---

 Cheap Ed Hardy |  Ed Hardy Shop |  Ed Hardy Sale |  Ed Hardy UK |  Ed Hardy Clothing |  Ed Hardy London |  Ed Hardy Apparel |  Ed Hardy T-Shirts