I've allready posted this in the RFE forum, but maybe this was not the best one. I haven't found how I could delete the first one.
Hello, I've began to work on the RFE #6356629. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6356629 The goal is to provide a number_to_scaled_string() function, which would be available for all people needing it. Currently, this function is used in ls, du, df and soon in swap. Each of these command tools do have its own number_to_scaled_string function, which is not a good idea. Furthermore, many other programs use such a function : *** [EMAIL PROTECTED] zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT junk 222G 71.6G 150G 32% ONLINE - ... *** [EMAIL PROTECTED] zfs list NAME USED AVAIL REFER MOUNTPOINT junk 71.6G 149G 151K /junk ... *** [EMAIL PROTECTED] prctl -t system $$ process: 27214: -csh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-port-events system 2.15G max deny - ... and certainly many others. I'd like the new function to be able to cover (allmost) all needs. The basic functionnality is to convert a given amount of bits to an output amount and output unit (the output unit is the one that fits best). I have thought a bit about it and I'd like to get some advices. [u]1. What are the needs ?[/u] As said before, it needs to convert an input value to an output value and output unit. Thus this could be written like this : int f(int in_value,int *out_value, char *out_unit) This would be really simple, but maybe would not cover most needs. Maybe users would need to give a scale as an argument (1000 or 1024 bits per block) ? Maybe they need to give the number of significative digits ? [u]2. What is the best way to do this ?[/u] This is not a question about implementing this, this is my work ;-) What I'd like to know is if there is a prefered way to return the result (an int for the value and another for the unit, a string, a string that is malloc'd, a string into the lib space that's overwritten each time the function is called ... ?) [u]3. Where should it be done ?[/u] I had been advised it [i]could[/i] be included into libadm. Any advices about it ? [u]4. Something else ?[/u] If you have any comments, suggestion, advice not covered in the above points ... Thank you. Yann This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] https://opensolaris.org:444/mailman/listinfo/opensolaris-code
