Tiny Core v12.0

[andyj]

@Rich Now that you point it out, yes it does not look like the division is necessary. Based on the surrounding code it is probably for consistency but I could clean it up for speed. There is another further down that I did not post that is used as an argument to some other function so it should stay:

Code: [Select]

+ unsigned long x = ktime_get_seconds();
- epoch_min = ktime_get_seconds() / 60;
+ epoch_min = do_div(x, 60);

@curaga Yes, I believe the time type should be time64_t, but throughout this module long is used so I am going to stick with that.

[Rich]

Hi andyj
Forget what I said.

... if a/c == b/c

to which my response would be:

then a == b ...

That's not true for integer math since the remainder gets discarded. I'm guessing the divide by 60 is to convert to
whole minutes and discard any fractional minute.

[bela.d]

Hi all,

I get a kernel panic after updating to v12.0 in VirtualBox Version 6.1.18 amd64 (Windows host).
The VM is Tiny Core x86.

Is anybody else using TC x86 in Virtualbox?

[andyj]

For the benefit of people who think TC is a minor distro and we can't create change in the world:

That's probably worth submitting upstream...

Done: https://www.spinics.net/lists/netfilter-devel/msg70361.html

[btlneck]

Hi andyj.
In the original code check peer for NULL prepends peer->login_sec reference.

Code: [Select]

static inline bool
 has_logged_during_this_minute(const struct peer *peer)
 {
- return peer != NULL && peer->login_sec / 60 == ktime_get_seconds() / 60;
+ unsigned long x = ktime_get_seconds();
+ unsigned long y = peer->login_sec;
+ return peer != NULL && do_div(y, 60) == do_div(x, 60);
 }

Excuse me for maybe stupid question, but if the

peer == NULL

whould this code work:

unsigned long y = peer->login_sec;

?

[Rich]

Hi btlneck
Welcome to the forum.

Nice catch. If  peer == NULL  then this will segfault:

Code: [Select]

unsigned long y = peer->login_sec;
Maybe casting the times to a long would work:

Code: [Select]

return peer != NULL && do_div((long)peer->login_sec, 60) == do_div((long)ktime_get_seconds(), 60);

[andyj]

This is a kernel module, so I would expect it to OOPS. There is a lot of "short circuit" type logic throughout this package, so in this case it should be something like this:

Code: [Select]

- unsigned long x = ktime_get_seconds();
- unsigned long y = peer->login_sec + autoclose_time * 60;
- return peer != NULL && autoclose_time != 0 && time_after(x, y);
+ if (peer != NULL) {
+ unsigned long x = ktime_get_seconds();
+ unsigned long y = peer->login_sec + autoclose_time * 60;
+ return autoclose_time != 0 && time_after(x, y);
+ } else {
+ return 0;
+ }

I can't post the whole patch here because our forum software apparently has a few bugs.

[Rich]

Hi andyj
Looks OK. This should work too:

Code: [Select]

if ((peer == NULL) || (autoclose_time == 0))
return 0;

unsigned long x = ktime_get_seconds();
unsigned long y = peer->login_sec + autoclose_time * 60;
return time_after(x, y);

[andyj]

That section of code doesn't have the original presenting problem of long division so it doesn't actually need the check anyway because the short circuit would work in that case, and thanks to trying to avoid our forum bug with patches I didn't post the part I should have:

Code: [Select]

static inline bool       
has_logged_during_this_minute(const struct peer *peer)
{                         
        if (peer != NULL) {
                unsigned long x = ktime_get_seconds(), y = peer->login_sec;
                return do_div(y, 60) == do_div(x, 60);
        } else {                     
                return 0;
        }             
}                         


[Rich]

Hi andyj

... and thanks to trying to avoid our forum bug with patches I didn't post the part I should have: ...

That explains it. I thought maybe I'd missed something.

The compiler won't add any code because of it, but the  return 0;  doesn't need to be wrapped in an  else  clause.

[andyj]

There are always different ways to code to get the same end result. In most cases I have learned to prefer towards the solution that reads most naturally and explains what is happening so I won't have to figure it out again the next time I look at it. How many times did I do this in my youth:



Or worse, come behind someone else?

[asm]

There are always different ways to code to get the same end result. In most cases I have learned to prefer towards the solution that reads most naturally and explains what is happening so I won't have to figure it out again the next time I look at it.

Hi, I don't know how I got here, but I suffer from XKCD 386 syndrome so when I saw this I felt the need to point out that there are very good reasons to prefer the early return approach: https://softwareengineering.stackexchange.com/questions/18454/should-i-return-from-a-function-early-or-use-an-if-statement

It's one of those things in programming I feel very strongly about. 

[Juanito]

Please note that glibc has been recompiled using uname_hack to force it to compile for i486.

rootfs.gz and the *Core* iso's have been replaced with ones containing the new glibc - as there is no corresponding change to CorePure, the version number has not been changed.

There is no need to update unless you have an i486 or similar.

[gadget42]

Please note that glibc has been recompiled using uname_hack to force it to compile for i486.

rootfs.gz and the *Core* iso's have been replaced with ones containing the new glibc - as there is no corresponding change to CorePure, the version number has not been changed.

There is no need to update unless you have an i486 or similar.

downloaded, good md5sum, good cd burn(boots fine in other machines), still fails on the amd k6-2 166mhz machine. using debug i get:

traps: wbar[1181] trap invalid opcode ip:b7ac0484 sp:bf97ad58 error:0 in libgcc_s.so.1[b7ac0000+16000]

sorry to be the bearer of bad news.

[Juanito]

libgcc_s.so.1 and libstdc++.so.6.0.28 have been recompiled using uname_hack to force i486.

rootfs.gz and the *Core* iso's have been replaced with ones containing the new gcc files - as there is no corresponding change to CorePure64, the version number has not been changed.

There is no need to update unless you have an i486 or similar.