Re: [HelenOS-devel] Benchmarks for scheduler refactor changes

Nice, thanks! :) Honestly, I have no idea why taskgetid benchmark, of all things, gets so much faster. I'm tempted to look into the cause now. -- jzr On Tue, Jan 23, 2024, 1:36 PM Jiri Svoboda wrote: > Hi, > > while I didn't have the time yet to go through the scheduler changes in > detail to

Re: [HelenOS-devel] How to display/interpret benchmark results?

I'm no statistics expert by any means, but if you're displaying rates, I'd do all computation with rates. It just seems like the least convoluted option. On Tue, Jan 23, 2024, 1:48 PM Jiri Svoboda wrote: > Hi, > > Currently hbench selects the number of cycles, takes 10 time measurements. > It

Re: [HelenOS-devel] Location of the 106th HelenOS project meeting

I'll probably be about 30 minutes late due to travel constraints. Looking forward to meeting you all again. -- J. Z. On Fri, Jan 12, 2024, 3:56 PM Martin Decky wrote: > Dear all, > > the location of the 106th HelenOS project meeting is the "Food Lab" > restaurant [1], Haštalská 749/4, 110 00

Re: [HelenOS-devel] Coastline builds failing on ci.helenos.org

On Mon, 13 Nov 2023 at 08:52, Vojtech Horky wrote: > > Hello, > > ne 22. 10. 2023 v 21:37 odesílatel Jiří Zárevúcky > napsal: > > On Sun, 22 Oct 2023 at 15:32, Jiri Svoboda wrote: > > > I fixed export.sh to deal with thin archives and fixed conflict in GZX > &

Re: [HelenOS-devel] Kernel framebuffer bottlenecks

I took another look at the root cause and it seems that the excessive slowness in emulator stems specifically from writing to framebuffer memory, since modifying the code to write to normal memory seems not to exhibit the slowdown. My hypothesis is that QEMU updates the display window on every

Re: [HelenOS-devel] Design thoughts on color scheme change notification mechanism

On Fri, 15 Sept 2023 at 13:19, Jiri Svoboda wrote: > > Hi, > > for quite some time I've been toying with the idea of implementing some color > scheme / color editing support in the UI. However, I've been stuck on the > design of a color scheme change notification mechanism. > > I think I've

Re: [HelenOS-devel] Coastline builds failing on ci.helenos.org

On Sun, 22 Oct 2023 at 15:32, Jiri Svoboda wrote: > > > Hi, > > I fixed export.sh to deal with thin archives and fixed conflict in GZX that > was causing its coastline build to fail. I went to check on ci.helenos.org if > it worked and now I see *all* coastline builds of all packages on >

Re: [HelenOS-devel] HelenOS Camp 2024

Yes! :) On Wed, Jul 26, 2023, 11:09 AM Jakub Jermář wrote: > Hi, > > the last HelenOS Camp took place in 2019. If there is enough interest, > I'd like to organize another one in the summer season of 2024 somewhere > in the Czech mountainous countryside (i.e. the good old HelenOS Camp). > > Let

Re: [HelenOS-devel] Commit messages (was: [HelenOS-commits] daadfa: Remove unnecessary context field from cpu_t structure)

On Mon, Feb 13, 2023, 12:21 AM Martin Decky wrote: > > That said, I'm in the process of changing the context switching code > > so that most of the structure becomes unnecessary. > > All that's really needed in context_t is IP, SP and possibly an > > argument field if we want to be fancy about

Re: [HelenOS-devel] [HelenOS-commits] daadfa: Remove unnecessary context field from cpu_t structure

On Sun, 12 Feb 2023 at 21:29, Martin Decky wrote: > > Dear Jiri Z., > > > Author: Jiří Zárevúcky > > Date: 2023-02-10T16:18:53+01:00 > > SHA1: daadfa699247351099d4c91048e2f9e9a29c346a > > URL: > > https://github.com/HelenOS/helenos/commit/daadfa6992473

Re: [HelenOS-devel] 104th HelenOS project meeting

Hello everyone, I won't make it this time. Don't wanna travel too much until the COVID situation settles down again. -- jzr On Tue, 6 Oct 2020 at 21:27, Jakub Jermář wrote: > > Hi, > > we would like to meet in person on Thursday evening in Prague for the > 104th HelenOS project meeting. Who

Re: [HelenOS-devel] HelenOS regular hangout Thursday, August 13 2020

Turns out I also can't make it tonight, sorry. There were two people in IRC who were interested in joining, so let them know if you go ahead with a hangout. On Thu, 13 Aug 2020, 13:44 Jakub Jermář, wrote: > Hi Jiri, > > On 8/12/20 2:49 PM, Jiri Svoboda wrote: > > I would like to remind regular

Re: [HelenOS-devel] Hangout Thursday, June 11, 21:30 GMT+0200

On Mon, 8 Jun 2020 at 13:45, Jiri Svoboda wrote: > > Hi, > > I would like to invite you to our regular hangout this Thursday, June 11, > starting at 21:30 GMT+0200. Please feel free to stop by. It does not matter > if you have anything to report or not. > > Also I figured out that Google

Re: [HelenOS-devel] Static analyzers after move to meson?

Hi, glad you asked! "make precheck" is effectively replaced by native meson functionality (it always generates a json file in build root containing the necessary information), but the scripts and documentation have not been updated yet. If I remember correctly, I discussed this with JJ and the

Re: [HelenOS-devel] Notes on last CI update

I apologize for my previous two messages. They are emotionally charged. Let's talk about how we can improve the "process" once I've cooled down a little. -- jzr On Wed, 13 Nov 2019 at 14:37, Jiří Zárevúcky wrote: > > On Wed, 13 Nov 2019 at 13:50, Jiri Svoboda wrote: > > &

Re: [HelenOS-devel] Notes on last CI update

On Wed, 13 Nov 2019 at 13:50, Jiri Svoboda wrote: > > Hi Jakub, > > I think we need to consider a few more things. The switch to Meson was a > big change and IMHO the outcome is overall very good and I am happy > about it. > > I think we regressed in a few more areas, the old build system made it

Re: [HelenOS-devel] Notes on last CI update

I requested review from everyone who is expressing their "woes". At some point, you have to accept that people have blind spots and if you refuse to participate for half a year before whining something you care about broke, well, that's not on me. CI gets low priority because nobody who actually

Re: [HelenOS-devel] XCW working with meson?

Hi, I'll look into it. Coastline should work fine. CI should work once the changes are deployed. As for XCW, I thought I checked that but I might have forgotten. On Mon, 11 Nov 2019, 21:49 Jiri Svoboda, wrote: > Hi, > > I tried running XCW in a meson-enabled mainline, but cannot get it to >

[HelenOS-devel] Heads up: switch to Meson build system

Hello everyone, We have wanted to move away from Make-based build for some time, and finally, the time has come. The mainline is now built using Meson, which gives us faster, more robust build, and easier to understand build scripts. The README and "compiling from source" wiki page have been

Re: [HelenOS-devel] Second attempt at HelenOS 101st meeting

On Wed, 1 May 2019 at 10:05, Jakub Jermář wrote: > > Hi, > > how about meeting in person in Prague on Thursday of May 9, around > 18:00? Let me know if this would suit you. If not, we fall back to a > hangout at 21:30. Note that there is a lecture on "Developing safe, > secure and real-time OS"

Re: [HelenOS-devel] 101st HelenOS project meeting

Maybe we can make an exception and postpone this month's meeting to next week? Unless it's inconvenient for someone else who can only join us this week. On Mon, 8 Apr 2019 at 10:08, Jiri Svoboda wrote: > > Hi, > > sorry no chance for me to make it to the meeting this week. Not that I have >

Re: [HelenOS-devel] 101st HelenOS project meeting

I'm fine with whatever day works best for most people. On Sun, 7 Apr 2019 at 13:48, Jakub Jermář wrote: > > Hi, > > we should have our 101st HelenOS project meeting next week. I am > wondering if people would rather like to meet on a weekend rather than > on Thursday evening as some commute from

Re: [HelenOS-devel] Problem with linking libc.so.0.0 on ppc32

Weird. I'm currently in the middle of some PC maintenance (scrubbing everything and installing a clean system), but I'll try to look into it as soon as possible. -- jzr On Tue, 15 Jan 2019 at 11:09, Jiri Svoboda wrote: > > Hi Jzr, > > while working on dynamic linking support for ppc32, I soon

Re: [HelenOS-devel] Any objections to enforcing blank lines not to contain indentation?

On Fri, 11 Jan 2019 at 10:06, Jiri Svoboda wrote: > > [...] > > Any objections to modifying ccheck to enforce that blank lines do not contain > any indentation? > I support this change. -- jzr ___ HelenOS-devel mailing list

Re: [HelenOS-devel] The 100th HelenOS project meeting

Any date in the two weeks leading up to xmas is fine with me. -- jzr On Wed, 28 Nov 2018 at 23:52, Vojtech Horky wrote: > > Hello, > > December 20 is fine with me, 13th as well. > > Cheers, > - Vojta > > so 24. 11. 2018 v 21:00 odesílatel Jakub Jermář napsal: > > > > Hi, > > > > we are going

Re: [HelenOS-devel] Switching away from Trac?

On Thu, 29 Nov 2018 at 10:14, Jiri Svoboda wrote: > > Exactly. I don't want to rely on GH too much. I'd prefer if we are able to > self-host all crucial infrastructure, like code and issues. I don't care so > much which system we use as long as it's owned by us. I'm still hoping to see > trac

Re: [HelenOS-devel] Harbours built but fails to run?

No, disregard that. That's not it. -_- On 29 May 2018 at 17:23, Jiří Zárevúcky wrote: > So, the issue seems to be that the toolchain builds executables with > dynamic relocations, which isn't supported on most platforms. > > I'll commit a workaround as soon as I finished check

Re: [HelenOS-devel] Harbours built but fails to run?

So, the issue seems to be that the toolchain builds executables with dynamic relocations, which isn't supported on most platforms. I'll commit a workaround as soon as I finished checking it works. -- jzr On 29 May 2018 at 08:17, Vojtech Horky wrote: > Hello, > > it seems that some recent

Re: [HelenOS-devel] Harbours built but fails to run?

On 29 May 2018 at 16:39, Jiri Svoboda wrote: > Maybe you're running out of memory? > Ah, yes, that sorts out the GUI problem, thanks. That part of it was due to the binaries including debug sections now. GCC still crashes though, so that's not the only problem.

Re: [HelenOS-devel] Harbours built but fails to run?

I can reproduce this. Also, if I build image with both gcc and binutils, the GUI itself consistently fails to start. I'll try to figure out what's going on. -- jzr On 29 May 2018 at 08:17, Vojtech Horky wrote: > Hello, > > it seems that some recent changes caused that harbours are being built >

Re: [HelenOS-devel] Formatting of Authors: comment

a/abi/include/_bits/NULL.h > +++ b/abi/include/_bits/NULL.h > @@ -26,7 +26,8 @@ > * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > */ > > -/* Authors: > +/* > + * Authors: > * Jiří Zárevúcky (jzr) <zarevucky.j...@gmail.com>

Re: [HelenOS-devel] Minutes of the 98th HelenOS project meeting

On 11 May 2018 at 19:20, Jakub Jermář wrote: > [...] > > Other topics: > > - JZr is planning to remove HelenOS linker scripts in favor of > compiler-provided ones > - there is a catch though: for some platforms also the > compiler-provided linker scripts must be patched, so it

Re: [HelenOS-devel] 98th HelenOS project meeting

Unfortunately, I won't be able to make it after all. I can join via a hangout if anyone is up to setting it up, though. -- jzr On 9 May 2018 at 07:14, Jakub Jermář wrote: > I made a reservation for 6 at Radegastovna Peron on Smichov > (http://www.peronsmichov.cz/) in the cellar

Re: [HelenOS-devel] 98th HelenOS project meeting

Hi, I'll be there! No preferences for the venue. -- jzr On 4 May 2018 at 16:25, Jakub Jermář wrote: > Hi! > > The 98th HelenOS project meeting will take place on Thursday of May > 11, shortly after 18:00 somewhere in Prague, Czech Republic. Please let > me know whether you plan

Re: [HelenOS-devel] What is the purpose of _HIDE_LIBC_SYMBOL(dlopen)?

On 18 March 2018 at 14:58, Jiri Svoboda wrote: > Hi Jzr, > > there is a macro defined expanding to empty body in: > ./uspace/lib/posix/src/internal/common.h:#define _HIDE_LIBC_SYMBOL(symbol) > > we use it in one place in > uspace/lib/posix/src/dlfcn.c > > what is the

Re: [HelenOS-devel] Linker script question

On 8 March 2018 at 20:30, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: > On 8 March 2018 at 20:12, Jakub Jermář <ja...@jermar.eu> wrote: >> On 03/08/2018 07:53 PM, Jiří Zárevúcky wrote: >>> I'm noticing that there are quite a few conditional parts in ia32 >>

[HelenOS-devel] Linker script question

I'm noticing that there are quite a few conditional parts in ia32 linker script. As you may know, I consider unnecessary conditional compilation to be An Evil Thing, thus I have to ask: Is there actually a technical reason why we can't have the same linker script for all configurations? -- jzr

[HelenOS-devel] Commit churn

Hello everyone, I accidentally pushed a wrong branch to mainline master, and force-pushed a correction a few minutes later. That's where the weird looking commit e-mails came from. It should be fine now, sorry about the noise. :) -- jzr ___

Re: [HelenOS-devel] riscv of helenOS

Hello, RISC V support is a work in progress. There is some basic support, but not enough to run the system. This is in part due to the fact that the privileged RISC V ISA (the part of the specification necessary to run a full featured OS) is not yet stabilized, so the platform is currently a

Re: [HelenOS-devel] Reopening the discussion about #pragma once

On 16 January 2018 at 13:47, Vojtech Horky <vojtech.ho...@gmail.com> wrote: > Hello. > > 2018-01-15 20:56 GMT+01:00 Jiří Zárevúcky <zarevucky.j...@gmail.com>: >>> - It's not standard. >>> >>> True, but meaningless. We use plenty of nonstandard extens

[HelenOS-devel] Reopening the discussion about #pragma once

So as to not keep hijacking unrelated thread... On 15 January 2018 at 20:43, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: > On 15 January 2018 at 20:29, Jakub Jermář <ja...@jermar.eu> wrote: >> On 01/15/2018 08:12 PM, Jiří Zárevúcky wrote: >>> On 15 Janua

Re: [HelenOS-devel] Reserved identifiers in libc

On 15 January 2018 at 20:29, Jakub Jermář <ja...@jermar.eu> wrote: > On 01/15/2018 08:12 PM, Jiří Zárevúcky wrote: >> On 15 January 2018 at 19:35, Jiri Svoboda <jirik.svob...@seznam.cz> wrote: >>> We've had discussion on #pragma once in june last year and agreed t

Re: [HelenOS-devel] Reserved identifiers in libc

g/JTC1/SC22/WG21/docs/papers/2017/p0538r0.html > > which is another point against using #pragma once. > I'm familiar with that paper, and the issues don't matter in current HelenOS. I'd be more interested in the old discussion. Where can I find it? > -- Původní e-mail --

Re: [HelenOS-devel] Reserved identifiers in libc

On 15 January 2018 at 17:04, Jakub Jermář <ja...@jermar.eu> wrote: > On 01/15/2018 04:29 PM, Jiří Zárevúcky wrote: >> On 15 January 2018 at 14:03, Jiri Svoboda <jirik.svob...@seznam.cz> wrote: >>> I agree that we shouldn't use non-reserved identifiers, because it's

Re: [HelenOS-devel] Reserved identifiers in libc

On 15 January 2018 at 14:03, Jiri Svoboda wrote: > I agree that we shouldn't use non-reserved identifiers, because it's > necessary to be standards conformant. However, using a _HELENOS prefix seems > too paranoid. The worst that could happen is that upon a compiler

[HelenOS-devel] Reserved identifiers in libc

Hello everyone. Since standard headers shouldn't define any non-standard, non-reserved identifiers, I hereby declare that identifiers starting with either '_HELENOS' or '__helenos' are reserved for use by our libraries. Any identifiers defined by our libraries that start with either two

[HelenOS-devel] Heads up: Error codes are non-negative now

-- jzr ___ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/listinfo/helenos-devel

Re: [HelenOS-devel] HelenOS Camp 2018 Early Planning

I have no concerns at this moment, and short of death or illness, I'll very certainly attend whatever the plan ends up being. -- jzr On 3 January 2018 at 20:54, Jakub Jermář wrote: > Dear HelenOS developers, > > let's start planning the HelenOS Camp 2018 really early. > > I

[HelenOS-devel] Last call for errno_t comments

Hello everyone and happy new year. I've been procrastinating a little about https://github.com/HelenOS/helenos/pull/10 (a monster of a change it is) but it's time to finally wrap it up. If anyone has been holding off on reviewing/commenting, now's your final opportunity. Unless unexpected

Re: [HelenOS-devel] Configuring routes & forwarding

Thanks! This helps a lot. On 18 December 2017 at 19:40, Jiri Svoboda wrote: > Hi JZr, > > to your question at the meeting regarding routing in HelenOS: > > - For an API to configure routes look at uspace/lib/c/include/inet/inetcfg.h > functions inet_sroute_*(). These are

Re: [HelenOS-devel] errno_t

On Dec 13, 2017 10:00 PM, "Jiří Zárevúcky" <zarevucky.j...@gmail.com> wrote: On Dec 13, 2017 6:08 PM, "Jiri Svoboda" <jirik.svob...@seznam.cz> wrote: > What do you mean by "collapsing the changesets"? Sorry, I wasn't clear. I meant you probably won

Re: [HelenOS-devel] errno_t

e bulk rename and the code fixes as separate changesets is obviously a very good idea. Regards, Jiri -- Původní e-mail -- Od: Jiří Zárevúcky <zarevucky.j...@gmail.com> Komu: HelenOS development mailing list <helenos-devel@lists.modry.cz> Datum: 12. 12. 2017 20:32:18

Re: [HelenOS-devel] errno_t

ng) was to keep the "rename" commit separate (it's huge, but by its nature it cannot introduce regressions). And perhaps split the manual changes into smaller parts. I'm open to suggestions, though. > > Best regards, > Jiri > > -- Původní e-mail -- > Od: Ji

[HelenOS-devel] errno_t

Hello everyone, I had promised to write an explanation for what I'm doing with error codes, and then was too exhausted to follow through, but better late than never. Here's the explanation of the motivation and methodology:

Re: [HelenOS-devel] [RFC] Locally extensible error returns

theories of error > handling since I've given the subject a significant amount of thinking time. > Having some basic guidelines for HelenOS might be useful (beyond mimic what > you see) but then we would have to agree to agree first :-) > Agreeing on common guidelines would be very nice. :)

Re: [HelenOS-devel] [RFC] Locally extensible error returns

ossibly doing the same thing doesn't make it less wrong. I lost you. This has little to do with errno_t. Are you saying every library should limit itself to constants? > -Jiri > > > -- Původní e-mail -- > Od: Jiří Zárevúcky <zarevucky.j...@gmail.com>

Re: [HelenOS-devel] [RFC] Locally extensible error returns

On 6 December 2017 at 22:04, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: > On 6 December 2017 at 21:20, Jiri Svoboda <jirik.svob...@seznam.cz> wrote: >> Hi Jiri, >> >> well this is maybe the least important problem that libhttp has. Why don't >> y

Re: [HelenOS-devel] [RFC] Locally extensible error returns

pletely separate type from errno_t? > Because that would be more difficult, as well as less beneficial in the long run. But of course, it's a possibility. -- jzr > Regards, > Jiri > -- Původní e-mail -- > Od: Jiří Zárevúcky <zarevucky.j...@gmail.com> > Komu: He

Re: [HelenOS-devel] [RFC] Locally extensible error returns

Clarification #2: Obviously, such errors cannot pass IPC boundary as is. I have several ideas how to work around that. On 6 December 2017 at 16:21, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: > Clarification: this would be used in addition to the errno.h codes, > not instead of.

Re: [HelenOS-devel] [RFC] Locally extensible error returns

Clarification: this would be used in addition to the errno.h codes, not instead of. There would be functions for translating between them. On 6 December 2017 at 16:17, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: > Hello, > For context: I've been working on fixing our errno.h use

[HelenOS-devel] [RFC] Locally extensible error returns

Hello, For context: I've been working on fixing our errno.h use for the past two days. It's going very well, I'll probably be done by tomorrow, and I'll write a blog post about the entire process after I'm finished. The issue I'm facing now is simple: libhttp uses errno.h error codes, but also

Re: [HelenOS-devel] musl as replacement for libposix

I don't have the energy to reply properly to this thread, yet. Suffice to say that I like what Vojta is doing, sans minor modifications which I'll propose on the meeting. There is one specific aspect of Jiri's response I just *have* to reply to: > Please don't tell me we don't have the resources

Re: [HelenOS-devel] The December meeting

On 4 December 2017 at 19:35, Jakub Jermář wrote: > Hi, > > how many people would be able to make it to the December meeting in > person? Probably on Dec 16 or 17? > Hi, Dec 16 is fine, but I'd prefer Dec 14-15, since I already have plans in Prague for those days. Dec 17 is too

Re: [HelenOS-devel] What is wrong with restrict parameters?

On 15 November 2017 at 17:09, Jakub Jermář <ja...@jermar.eu> wrote: > On 11/15/2017 04:43 PM, Jiří Zárevúcky wrote: >> On 15 November 2017 at 16:36, Jakub Jermář <ja...@jermar.eu> wrote: >>> On 11/15/2017 04:21 PM, Jiří Zárevúcky wrote: >>>>> Out of cur

Re: [HelenOS-devel] What is wrong with restrict parameters?

On 15 November 2017 at 16:36, Jakub Jermář <ja...@jermar.eu> wrote: > Hi Jiri, > > On 11/15/2017 04:21 PM, Jiří Zárevúcky wrote: >>> Out of curiosity, which C89-only code is being compiled against libposix? >>> >> >> libuv compiles as

Re: [HelenOS-devel] What is wrong with restrict parameters?

On 15 November 2017 at 15:59, Vojtech Horky <vojtech.ho...@gmail.com> wrote: > 2017-11-15 15:49 GMT+01:00 Jiří Zárevúcky <zarevucky.j...@gmail.com>: >> On Nov 15, 2017 15:20, "Ondřej Hlavatý" <aear...@eideo.cz> wrote: >>> strictly speaking, coul

Re: [HelenOS-devel] What is wrong with restrict parameters?

variable/function name. Identifiers starting with two underscores are reserved, so the same problem doesn't apply for __restrict__. On 15.11., Jiří Zárevúcky wrote: > Hi, > > the reason is that "restrict" wasn't a keyword before C99, so those headers > couldn't be incl

Re: [HelenOS-devel] What is wrong with restrict parameters?

Hi, the reason is that "restrict" wasn't a keyword before C99, so those headers couldn't be included in code written for C89. __restrict__ is non-standard, but that doesn't limit its usability in any way -- if you want to use a compiler that doesn't support it, you can just define __restrict__ to

Re: [HelenOS-devel] Getting ready for release

- 705 seems like a configuration issue on the user side to me, or am I wrong? Possibly, but I want to investigate what's going on there. Just got held up installing CentOS. Either way, it shouldn't block release. -- jzr ___ HelenOS-devel mailing

[HelenOS-devel] Heads up: Makefile changes

Hello everyone, as of now, library dependencies in uspace Makefiles are declared by name (no path, no lib- prefix, no need for separate include flags). If your local branch has any modules that don't exist upstream, you will need to manually update the Makefiles when you merge from mainline. In

[HelenOS-devel] Knot_resolver_port_mutex.try_lock()

Hello everyone, Starting next week, I'll be looking into porting knot resolver (and its dependencies[0]) to coastline. Does anyone have any secret branches that could contain duplicate work? -- jzr [0] https://knot-resolver.readthedocs.io/en/stable/build.html#requirements

Re: [HelenOS-devel] Build problems

By the way, switch to git could help avoid this kind of thing. :) It would be nice to let minor changes stew in a personal branch for a little while, but bzr with its shoddy support for rebasing makes that painful. -- jzr On 21 October 2017 at 21:11, Jiří Zárevúcky <zarevucky.j...@gmail.

[HelenOS-devel] Fwd: Build problems

Hi Jiri, :) On 21 October 2017 at 20:05, Jiri Svoboda wrote: > Hi Jiri, > > after your recent changes, I am having some problems: > - build fails if uspace/overlay is empty Oops! Yes, that's totally my mistake. I'll fix it right now. -- jzr

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

So I went ahead and pushed your change, plus fixes for all the other warnings I got. Let me know if you find anything else. Thanks! -- jzr P.S.: Fun fact! Your name crashed the server-side python scripts. That's probably why there's no mail about the commits. :D On 20 October 2017 at 01:49,

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

nown-elf > --program-prefix=amd64-unknown-elf- --with-gnu-as --with-gnu-ld --disable-nls > --disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib > --disable-libgcj --without-headers --disable-shared --enable-lto > --disable-werror > Thread model: single

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

h-gnu-as --with-gnu-ld --disable-nls > --disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib > --disable-libgcj --without-headers --disable-shared --enable-lto > --disable-werror > Thread model: single > gcc version 7.1.0 (GCC) > > OH > > On 20.10.

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

Hmm, seems I spoke too soon. I tries -O0, but not -Og. -Og does throw those warnings at me. On 20 October 2017 at 01:36, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: > The weirdest part that as far as I can tell, those are legit bugs. > > On my end, I get no warnings whatso

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

Oh, wait. Those are actually fine. I didn't see it at first. But to get those right, the compiler needs a fairly elaborate understanding of integer ranges. Maybe you are missing one of the optional dependencies? On 20 October 2017 at 01:36, Jiří Zárevúcky <zarevucky.j...@gmail.com>

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

rect-seg-refs -g -I../../../../lib/drv/include -c pci.c -o pci.o > -Og > > pci.c: In function 'pci_conf_write': > pci.c:322:7: error: 'val' may be used uninitialized in this function > [-Werror=maybe-uninitialized] >val &= ~(0xffU << ((reg & 3) * 8)); > > How does

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

: > Hi, > > On 19.10., Jiří Zárevúcky wrote: >> Could you elaborate on your setup? >> In particular, do you use the proper cross-compiler, as built using >> toolchain.sh? > > I just installed fresh toolchain, distclean, loaded amd64 defaults and > it happened. Strangely, no

Re: [HelenOS-devel] Modular types for fun and profit

Last call for comments! It seems the change is generally well accepted, so I'll merge it first thing on Monday, including any necessary fixes to coastline and ci. -- jzr On 17 October 2017 at 20:49, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: > Forgot to add, you can see a

Re: [HelenOS-devel] [MERGE] Do not use uninitialized variables

Hello Ondra, I regret to say, I can't reproduce any of what you are describing. Could you elaborate on your setup? In particular, do you use the proper cross-compiler, as built using toolchain.sh? Also, did you add any additional compiler flags? Any other changes? Differences from default

Re: [HelenOS-devel] Modular types for fun and profit

Forgot to add, you can see a diff here: https://github.com/le-jzr/helenos/compare/master...le-jzr:types -- jzr On 16 October 2017 at 20:03, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: > Hello everyone, > so, after more tinkering and adjustments, I've arrived at a state I > fi

Re: [HelenOS-devel] Modular types for fun and profit

of common.h to conditionally define missing macros; at this moment, the header is not used anywhere, because it's not needed when building with gcc or clang, but it can be used as a fallback to e.g. support building stuff using pcc) -- jzr On 11 October 2017 at 16:32, Jiří Zárevúcky <zarevuck

Re: [HelenOS-devel] [HelenOS-tickets] [HelenOS] Trac email verification for user: smithjohn

On 15 October 2017 at 02:50, HelenOS wrote: > Please visit the following URL to confirm your email address. > > Verification URL: > > Username: smithjohn > Verification Token: [redacted] I'd say that broadcasting

Re: [HelenOS-devel] git

On 12 October 2017 at 22:20, Jakub Jermář <ja...@jermar.eu> wrote: > On 10/12/2017 09:55 PM, Jiří Zárevúcky wrote: >> On 12 October 2017 at 21:42, Jan Vesely <jano.ves...@gmail.com> wrote: >>> I've added a 'merged' branch to the experimental git repo [0]. It >>&

Re: [HelenOS-devel] git

On 12 October 2017 at 21:42, Jan Vesely wrote: > Hi, > > > I've added a 'merged' branch to the experimental git repo [0]. It > incudes all older svn + bzr history. It also preserves the committer > information. > The script runs ~5mins and the hashes are the same every time

Re: [HelenOS-devel] [HelenOS-commits] [mainline] r2804 - Add as a wrapper for , and eliminate direct references to the latter.

On 11 October 2017 at 17:54, Jiří Zárevúcky <zarevucky.j...@gmail.com> wrote: >> >> Either that or or a non-legacy name, but no sys/*, please. >> > > Ok, I'll change it to for now. > Actually, we already have , so how about ? -- jzr

Re: [HelenOS-devel] [HelenOS-commits] [mainline] r2804 - Add as a wrapper for , and eliminate direct references to the latter.

On 11 October 2017 at 17:51, Jakub Jermář <ja...@jermar.eu> wrote: > On 10/11/2017 05:28 PM, Jiří Zárevúcky wrote: >> On 11 October 2017 at 17:16, Jakub Jermář <ja...@jermar.eu> wrote: >>> On 10/11/2017 04:51 PM, Jiří Zárevúcky wrote: >>>> On 11 October 20

Re: [HelenOS-devel] [HelenOS-commits] [mainline] r2804 - Add as a wrapper for , and eliminate direct references to the latter.

On 11 October 2017 at 17:16, Jakub Jermář wrote: > > There is objectively no reason why introduce new POSIX names that do not > even carry POSIX-compliant content. As you may know, there is now a > doctrine in the HelenOS community against naming things in this way > (reusing

Re: [HelenOS-devel] [HelenOS-commits] [mainline] r2804 - Add as a wrapper for , and eliminate direct references to the latter.

On 11 October 2017 at 17:16, Jakub Jermář <ja...@jermar.eu> wrote: > On 10/11/2017 04:51 PM, Jiří Zárevúcky wrote: >> On 11 October 2017 at 08:17, Jakub Jermář <ja...@jermar.eu> wrote: >>> Hi Jiri, >>> >>> On 10/11/2017 04:04 AM, Jiří Zárevúcky wro

Re: [HelenOS-devel] [HelenOS-commits] [mainline] r2804 - Add as a wrapper for , and eliminate direct references to the latter.

On 11 October 2017 at 08:17, Jakub Jermář <ja...@jermar.eu> wrote: > Hi Jiri, > > On 10/11/2017 04:04 AM, Jiří Zárevúcky wrote: >> On Oct 11, 2017 12:09 AM, "Jakub Jermář" <ja...@jermar.eu >> <mailto:ja...@jermar.eu>> wrote: >> >>

Re: [HelenOS-devel] Modular types for fun and profit

On 11 October 2017 at 08:27, Jakub Jermář wrote: > >> However, the building block headers don't contain the actual >> definition of those types and constants, they simply refer to >> preestablished macros with reserved names, such as __SIZE_TYPE__. >> These macros are established

[HelenOS-devel] Modular types for fun and profit

Hello everyone, it's time to share something I've tinkering with for a few days. First, motivation: There's a couple of identifiers in libc (both types and constants), that are special in ways that make organization difficult. On one side, we have things like size_t and NULL that are supposed to

Re: [HelenOS-devel] [HelenOS-commits] [mainline] r2804 - Add as a wrapper for , and eliminate direct references to the latter.

On Oct 11, 2017 12:09 AM, "Jakub Jermář" wrote: Hi jzr, > [...] > Added: > uspace/lib/c/include/sys/types.h This commit reintroduces a POSIX header file (at least by name) which I removed a couple of months back. Any evil intentions? Yes, yes, much evil. I plan to move

Re: [HelenOS-devel] Heads up: Changing crosscompiler target for amd64

r to generate more efficient code. I think I need to do more > staring into the TLS spec to understand why it doesn't work for us at the > moment... > > Cheers, > Jiri > ------ Původní e-mail -- > Od: Jiří Zárevúcky <zarevucky.j...@gmail.com> > Komu:

Re: [HelenOS-devel] [HelenOS] C++ Port Thesis

Hello Jaroslav! Nice to see someone working on this, and thanks for linking in the ML. I can help answer some of the questions. The state of HelenOS libc and libposix is far from ideal, and it's going to keep evolving in the coming months. Ideally, libc should eventually be compatible with C and

[HelenOS-devel] Heads up: Changing crosscompiler target for amd64

In order to fix clang build on amd64, I'm changing its target from amd64-linux-gnu to amd64-unknown-elf. The reason for this is that clang doesn't support "-mno-tls-direct-seg-refs", which is necessary for HelenOS to work when using a Linux target. It's an OS-specific optimization, so changing

[HelenOS-devel] Heads up: Change to toolchain path

Hello everyone! I have committed a small change to our cross-compiler toolchain paths. After the change, toolchains will be installed into "$CROSS_PREFIX//" instead of "$CROSS_PREFIX//". For example, a toolchain that would have been in "$CROSS_PREFIX/arm32/" before will now be installed to

Re: [HelenOS-devel] Unlimited recursion in e1000_link_restart()

Excellent! Thanks for taking a look. :) -- jzr On 6 October 2017 at 19:52, Zdenek Bouska wrote: > Hi, > > The recursion was not intended. > > I think that the fix is all right. Thanks Jiri! > > Zdenek > > On Wed, Oct 4, 2017 at 9:20 PM, Jakub Jermář

  1   2   3   >