[PATCH] Removed use of 64-bit function, use 64-bit types in usr.bin/top/top.c

[prasannatsmkumar]

Hi All,

I have removed use of 64-bit functions (minix/u64.h) from usr.bin/top/top.c and instead of that started using 64-bit data types (long, unsigned long, etc). As the current compilers (gcc, clang) supports them there is no need of using 64-bit functions. It is available in https://github.com/prasannatsm/Minix_remove_u64/commit/68fd2f50b81eb985a425e0bbf7f9c2b833b9a096 (diff form).

I ran modified top and I was able to get values shown properly. I compared the load averages and they appear the same in minix's top and modified top :). It will be great if people could review, possibly merge if there is no further changes required. Please feel free to add review, comments.


This is a first step towards removing the use of minix/u64.h completely from Minix. I am planning to work on removing the use of 64-bit functions in coming days. I will be removing it module by module so that it will be easier for reviewing / merging.

Thanks and Regards,
PrasannaKumar

[Antoine LECA]

prasannatsmkumar wrote:
> I have removed use of 64-bit functions (minix/u64.h) from usr.bin/top/top.c

Good

> and instead of that started using 64-bit data types (long, unsigned long,

You meant int64_t, uint64_t, didn't you?

BTW: Please do not consider long long for 64-bit operations like the
ones involved here: while it is 64 bits on most platforms these days,
there *are* guarantees some future platform might use 128 bits in the
future, and there is anticipated chaos here; and this is the very reason
why int64_t have been designed.


Antoine

[prasannatsmkumar]

On Fri, Sep 28, 2012 at 1:13 PM, Antoine LECA <antoine...@gmail.com> wrote:

prasannatsmkumar wrote:
> I have removed use of 64-bit functions (minix/u64.h) from usr.bin/top/top.c

Good

> and instead of that started using 64-bit data types (long, unsigned long,

You meant int64_t, uint64_t, didn't you?

Yes, I meant to say u64_t and friends.
 

BTW: Please do not consider long long for 64-bit operations like the
ones involved here: while it is 64 bits on most platforms these days,
there *are* guarantees some future platform might use 128 bits in the
future, and there is anticipated chaos here; and this is the very reason
why int64_t have been designed.

Antoine

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

Thanks and Regards,
PrasannaKumar

[D.C. van Moolenbroek]

Hi,

On Sep 27, 8:40 pm, prasannatsmkumar <prasannatsmku...@gmail.com>
wrote:

> Please feel free to add review, comments.

Done.

Regards,
David

[prasannatsmkumar]

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

Thanks David for your review.

I have made further changes based on previous reviews. Please have a look at https://github.com/prasannatsm/Minix_remove_u64/commit/d7ce07181ab4aa6c9e89f37d183169ae42b64088

Planning to do some slight changes if possible.

Thanks and Regards,
PrasannaKumar

[D.C. van Moolenbroek]

Hey PrasannaKumar,

On Friday, September 28, 2012 6:33:46 PM UTC+2, PrasannaKumar T S M wrote:

I have made further changes based on previous reviews. Please have a look at https://github.com/prasannatsm/Minix_remove_u64/commit/d7ce07181ab4aa6c9e89f37d183169ae42b64088

Sorry for the delay and thank you for following up! I would still highly recommend that you also process the comment I made about the make64/ex64lo/ex64hi changes. Basically, getting rid of minix/u64.h completely is not the best plan right now, because many places still require conversion between 64-bit values and pairs of 32-bit values. An example of that is 64-bit values versus 32-bit fields of "struct message" as pikpik correctly noted. Those three macros are a much cleaner way of doing that than explicit casting, bit shifting, etcetera. So in the case where there is no simple alternative (like replacing make64(0,0) with just 0, which of course is fine), I would keep these three macros as they are. Ideally, minix/u64.h would contain just those three macros in the end - and nothing else.

Thank you,
David

[prasannatsmkumar]

--

You received this message because you are subscribed to the Google Groups "minix3" group.

To view this discussion on the web visit https://groups.google.com/d/msg/minix3/-/VAWgDT_AaYEJ.

To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

Yes use of make64 is useful till breaking 64 bit values to two 32 bit (high and low) is modified in other parts (in this case it is procfs). This also makes the code look better. Done. Please have a look at link https://github.com/prasannatsm/Minix_remove_u64/commit/cb425089662ea36f4c127ee07a6af053c5ab9b89. Thanks for the review.

Thanks and Regards,
PrasannaKumar

[D.C. van Moolenbroek]

Hey,

On Oct 14, 2:59 pm, prasannatsmkumar <prasannatsmku...@gmail.com>
wrote:
> [..] Done. Please have a look at [..]

That looks good. IMO we can merge it now.

Thanks again,
David

[prasannatsmkumar]

 Thanks a lot David.

Thanks and Regards,
PrasannaKumar

[Ben Gras]

Pushed to master. Thanks for your contribution!

(I added some minor top functionality, removed new warnings from top, and cleaned up the commit message a bit, squashed the commits, and added a (u64_t) cast that I think was necessary to make the operation remain 64bit result.)

[prasannatsmkumar]

Nice and happy to see :). This is my first contribution to an existing open source project in form of code. Hope I could do more contributions.

Thanks,
PrasannaKumar

[prasannatsmkumar]

On Tue, Oct 16, 2012 at 12:01 AM, Velmurugan Moorthy <velmuru...@gmail.com> wrote:

Could anybody explain me how to start contributing to minix...? please. I'm also interested..

Please have a look at the how to contribute to minix3 (http://wiki.minix3.org/en/HowToContribute), feature wishlist (http://wiki.minix3.org/en/Wishlist?action=show&redirect=MinixWishlist) and talk to people on irc (#minix). You can get some idea on what to do. I guess you can start from very simple code contribution like what I have done and move forward.

Hope this helps,
PrasannaKumar

[Ben Gras]

Perfect summary, PrasannaKumar. If anyone would like to start a 'contributing to minix from scratch' wiki page that would be helpful.

I'll add the broken packages to the wishlist.

[prasannatsmkumar]

I have wrote a blog post on my experience, it is available at http://prasannakumartsm.wordpress.com/2012/10/24/my-experiences-in-contributing-to-minix-3/

I have written what came to mind and it may not be well structured. Please have a look at it. It may encourage some to start contributing to minix :).

--

You received this message because you are subscribed to the Google Groups "minix3" group.

To view this discussion on the web visit https://groups.google.com/d/msg/minix3/-/-QvaXfldv6AJ.

To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

Thanks and Regards,
PrasannaKumar