diff options
Diffstat (limited to 'microkernel/mach/gnumach')
| -rw-r--r-- | microkernel/mach/gnumach/boot_trace.mdwn | 22 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/debugging.mdwn | 23 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/interface.mdwn | 38 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/interface/device/time.mdwn | 88 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/interface/syscall/mach_print.mdwn | 32 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/ports/xen.mdwn | 208 | ||||
| -rw-r--r-- | microkernel/mach/gnumach/projects/clean_up_the_code.mdwn | 111 |
7 files changed, 509 insertions, 13 deletions
diff --git a/microkernel/mach/gnumach/boot_trace.mdwn b/microkernel/mach/gnumach/boot_trace.mdwn index 7b729c23..ea999a9b 100644 --- a/microkernel/mach/gnumach/boot_trace.mdwn +++ b/microkernel/mach/gnumach/boot_trace.mdwn @@ -227,3 +227,25 @@ License|/fdl]]."]]"""]] >> vm\_pageout >> Does not return. + + +# IRC, freenode, #hurd, 2013-10-07 + + <cureOS> look, where should i dig or where from should i start from, if i + have desire to know how the kernel was written from baremetal? Can it be + ever done nowadays? + <youpi> cureOS: the boot entry of the kernel is i386/i386at/boothdr.S , + boot_entry + <youpi> that's what grub jumps to + <youpi> then that jumps to c_boot_entry + <youpi> and everything else is C + <cureOS> grub loads it somehow. how does it prepare cpu and memoty, cpu + cache control if any... segments for stack.. + <youpi> see the grub documentation + <youpi> basically it's all flat linear space + <cureOS> does kernel transform it after that? + <youpi> see the ldt/gdt initialization + <youpi> from i386at_init and children + <youpi> nothing much fancy, a kernel cs/ds, and user cs/ds + <braunr> and paging, naturally + <youpi> sure diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 7e7cfb4e..cf02471d 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012, 2013, 2014 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -135,7 +135,7 @@ update its display buffer anymore under certain conditions. # Halting the CPU and Examining Registers -IRC, freenode, #hurd, 2011-07-14: +## IRC, freenode, #hurd, 2011-07-14 <braunr> one ugly trick i use when printf isn't available is to halt the cpu @@ -146,7 +146,22 @@ IRC, freenode, #hurd, 2011-07-14: # Serial Console -IRC, freenode, #hurd, 2011-11-13: +## IRC, freenode, #hurd, 2011-11-13 <youpi> use console=com0 <youpi> to activate the console on the first serial port + + +# `ud2` instruction + +## IRC, freenode, #hurd, 2013-10-31 + + [master-x86_64] + <phcoder> GNU Mach 1.3.99 + <phcoder> Running on xen-3.0-x86_64. + <phcoder> AT386 boot: physical memory from 0x0 to 0x40000000 + <youpi> \o/ + <phcoder> well when loaded through pvgrub2 i hangs without any message + <phcoder> any pointers on debugging? + <youpi> I usually put the ud2 instruction along the path to see where it + crashes diff --git a/microkernel/mach/gnumach/interface.mdwn b/microkernel/mach/gnumach/interface.mdwn index b2451887..bfcb9ea6 100644 --- a/microkernel/mach/gnumach/interface.mdwn +++ b/microkernel/mach/gnumach/interface.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -14,3 +14,39 @@ License|/fdl]]."]]"""]] [[!map pages="microkernel/mach/gnumach/interface/*" show=title]] + + +# Proposed + +## Futex + +### Patches on bug-hurd + +### IRC, freenode, #hurd, 2014-01-20 + + <teythoon> braunr: i meant to ask about the futex stuff + <teythoon> what do you mean when you talk about the interface ? + <teythoon> i imagined something like this + <braunr> more precisely ? + <teythoon> for shared futexes, do not use a pointer, but a right + referencing a memory object, and the offset ? + <braunr> why not a pointer ? + <braunr> well, an address + <teythoon> that's how it's currently done, right ? + <teythoon> in marins prototype i mean + <braunr> yes + <braunr> it's a task/address pair + <teythoon> so the only concern is the access in the kernel ? + <braunr> hum not only no + <braunr> or yes, but there are multiple ways to access + <teythoon> i meant to say this, for me, it would be very helpful if you + were more explicit when you describe how you picture something + <braunr> i thought i did it clearly + <braunr> i even agree with what roland describes + <braunr> which looks even clearer + <braunr> also, i said i didn't picture it completely + <braunr> :) + <braunr> i didn't want to work on that, only review + <teythoon> sure, but what might be clear to you is most likely not that + clear to me + <braunr> ok diff --git a/microkernel/mach/gnumach/interface/device/time.mdwn b/microkernel/mach/gnumach/interface/device/time.mdwn index d1e9a488..18681f21 100644 --- a/microkernel/mach/gnumach/interface/device/time.mdwn +++ b/microkernel/mach/gnumach/interface/device/time.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -16,3 +16,89 @@ Typically available as `/dev/time`, [[hurd/translator/storeio]]. Using that, [[hurd/libshouldbeinlibc]]'s `<maptime.h>` provides `maptime_map` and `maptime_read`, see the [[hurd/reference_manual]]. Candidate for replacement with [[open_issues/vDSO]] code? + + +# IRC, freenode, #hurd, 2013-11-20 + + <teythoon> braunr: about the mach device interface, if i open a device, and + then create a memory mapping using device_map, does that increment the + open count of the device ? + <teythoon> can i call device_close w/o destroying the mapping directly + after mapping it ? + <antrik> teythoon: I have a vague recollection that the mapping (or more + precisely, the memory object) is not bound to the open once + established... but don't take my word on it -- it's been some years since + I played with that stuff :-) + <teythoon> antrik: yes, that would actually match my expectation + <braunr> hum + <braunr> normally, mapping increments the usage count of the resource + mapped, but not the open count + <braunr> i don't know if that's the case for mach devices + <braunr> teythoon: which mach device btw ? + <teythoon> time + <teythoon> libshouldbeinlibc/maptime.c line ~53 + <teythoon> the device is opened but never closed + <braunr> is that a problem ? + <teythoon> not sure, but I'd think so, yes + <braunr> why ? + <teythoon> the open count is incremented each time + <braunr> at map time ? + <braunr> ah no, since that's your question + <braunr> the open count is normally decremented when the send right for the + device is destroyed, which occurs when tasks exit + <teythoon> hm + <teythoon> but wouldn't only important long running servers use the mach + device ? + <braunr> all tasks do + <braunr> a simple call to gettimeofday will use it + <teythoon> well, but only privileged processes may get teh device master + port + <braunr> the device is probably accessible through some other method + <teythoon> yes. /dev/time + <teythoon> err, have you looked at the function ? ;) + <braunr> no + <braunr> which one ? + <teythoon> maptime_map + <braunr> i did once but quickly + <teythoon> if use_mach_dev, the mach device is used, /dev/time otherwise + <braunr> gettimeofday apparently uses __host_get_time + <braunr> mhmm + <braunr> ok so i was wrong + <braunr> the time device, whether it is the mach or the hurd one, seems to + be mapped only by translators + <braunr> 14:10 < teythoon> but wouldn't only important long running servers + use the mach device ? + <braunr> so yes :) + <teythoon> so we should close the device + <braunr> why ? + <teythoon> to prevent an overflow in the open count + <braunr> when is it open multiple times ? + <teythoon> isn't it ? maybe /me lacks some context ;) + <braunr> it's called once at init time + <teythoon> well, ok then + <braunr> gettimeofday-like functions then only read the mapped memory + <braunr> at least, that's how it's done in the servers i've looked at such + as pfinet + <teythoon> makes sense, yes + <braunr> something i learnt from experience and failures: check the problem + actually exists before fixing it :p + <teythoon> well, if the memory mapping is independent of the device, then + there is a problem + <teythoon> the device is kept open for no reason + <braunr> teythoon: if you can determine that the device doesn't need to + stay open for the mapping to remain, then you can close it + <braunr> otherwise, it's such a minor leak that we don't care at all + <braunr> i wouldn't even consider it a leak more than a small static + variable used at init time only + <teythoon> looks like, yes + <teythoon> also, it's only in the rootfs translator + <braunr> ? + <teythoon> only the root filesystem uses the mach device directly + <braunr> ok + <braunr> well, /dev/time too right ? + <teythoon> yes, but that is a storeio translator that does not use this + code + <braunr> yes + <braunr> hm + <teythoon> only the root filesystem uses the mach device directly *using + this function* diff --git a/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn index a169e92e..d03c9674 100644 --- a/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn +++ b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -88,3 +88,33 @@ License|/fdl]]."]]"""]] the caller's address space without going through a special copy-from-user function <braunr> not very portable + + +## IRC, freenode, #hurd, 2013-11-25 + + <teythoon> can we get the mach_printf function somewhere so that it's + easier to use please ? + <braunr> well + <braunr> i'm not comfortable with that + <teythoon> y not ? + <braunr> i don't consider mach_print being part of the interface yet + <teythoon> ... + <braunr> it's really a debugging call + <braunr> not always available + <teythoon> so what, let it fail if it is not + <braunr> ok + <braunr> i should change it first + <braunr> pass a size argument + <braunr> and do a proper copyin + <teythoon> cool, thanks :) + <braunr> then we could add that printf function in libshouldbeinlibc i + guess + <teythoon> that'd be nice, yes + <braunr> hm + <braunr> that would make only hurd servers able to use it though + <braunr> unless we preload it + <teythoon> well, i thought it's a staging area for libc ? + <braunr> in theory yes, in practice some functions have been stuck there + for ages + <braunr> we'll discuss that with youpi and tschwinge + <braunr> and pinotree diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index c6023786..a8a1fcbf 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2013, 2014 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -96,6 +96,176 @@ Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use extra is now the path to the grub config file. + +## IRC, freenode, #hurd, 2013-11-09 + + <phcoder> youpi: would a limitation of 32 modules to hurd in pvgrub2 be a + problem? + <phcoder> *31 + <youpi> phcoder: probably not + <phcoder> youpi: ok + + <phcoder> youpi: gnumach goes into infinite loop with "warning: nsec + 0x000096dae65d2697 < lastnsec 0x000096db11dee20d". Second value stays + constant, first value loops from 0x000096da14968a59 to + 0x000096db08bf359e. Not sure if the problem is on GRUB or gnumach ide + <youpi> loops?! + <youpi> that's the time coming from the hypervisor + <youpi> not a problem from GRUB anyway + <phcoder> Yes, loops in steps of around 0x40 and comes back regularly. + <youpi> Mmm, maybe it could be grub not properly setting up + hyp_shared_info.vcpu_info[], actually + <youpi> i.e. the mfn in boot_info.shared_info + <phcoder> I don't think we write to shared page at all + <phcoder> could gnumach suffer from overflow on fast CPU? + <phcoder> next_start.shared_info = grub_xen_start_page_addr->shared_info; + <phcoder> And shared_info is machine address, so no need to adjust it + <phcoder> tsc_shift can be negative. Does gnumach handle this? + <youpi> yes + <youpi> here it's the base which doesn't change, actually + <phcoder> Do you mean this: system_time = + time->system_time; ? + <phcoder> But wait: ((delta * (unsigned64_t) mul) >> 32) + <phcoder> this overflows after 2^32 nanoseconds + <phcoder> which is about 4 seconds + <phcoder> I think this is the mistake + <phcoder> which is more or less what I see + <phcoder> Let me make a patch + <youpi> does xen have some tickless feature now? + <youpi> I'd expect the clock to get updated at least sometimes during 4 + seconds :) + <phcoder> Hm, can't compile master: + <phcoder> ./include/mach/xen.h:52:18: error: ‘MACH2PHYS_VIRT_START_PAE’ + undeclared (first use in this function) + <phcoder> #define PFN_LIST MACH2PHYS_VIRT_START_PAE + <phcoder> Here is the patch: http://paste.debian.net/64857/ + <youpi> it's defined in xen/public/arch-x86/xen-x86_32.h + <phcoder> yes it is. Let's see why it's not included + <phcoder> Hm, for some reason it pulls 64-bit headers in + <youpi> how do you cross-compile? + <youpi> I use + <youpi> ./configure --host=i686-gnu CC='gcc -m32' LD='ld -melf_i386' + <phcoder> Yes. GRUB adds those itself + <phcoder> youpi: confirmed: my patch solves the problem + <phcoder> any yes: I tried with unpatched master and it fails + <youpi> ok + <youpi> phcoder: thanks! + + <phcoder> Now I get plenty of "getcwd: cannot access parent directories: + Inappropriate file type or format". But I don't think it's grub-related + <youpi> what do you get before that? + <youpi> perhaps ext2fs doesn't get properly initialized + <youpi> which module commande line do you get in the boot log? + <youpi> perhaps it's simply a typo in there + <phcoder> http://paste.debian.net/64865/ + <youpi> $(task-create) $(task-resume) is missing at the end of the ext2fs + line indeed + <youpi> in your paste it stops at $( + <phcoder> this is at the end of my console. I believe it to be + cosmetic. Let me reset console to some sane state + <youpi> ok + <youpi> the spurious event at the start is probably worth checking up + <youpi> it looks like events that pvgrub2 should have eaten + <youpi> (in its own drivers, before finishing shutting them down) + <phcoder> when redirecting console to file: http://paste.debian.net/64868/ + <phcoder> could swapon have sth to do with it? + <youpi> I'd be surprised + <phcoder> my guess it's because I use older userland (debian about May) and + new kernel (fresh from master) + <youpi> the kernel hasn't really changed + <youpi> you could rebuild the may-debian kernel with your patch to make + sure + <youpi> but probably better trying to fix swapon first, at least + <youpi> (even if that'd surprise me) + <youpi> "trying fixiing* swapon", actually + <youpi> it makes a difference :) + <phcoder> We actually never eat event on evtchn, we look into buffers to + check for response + <youpi> ah, that's why + <youpi> you should really eat the events too + <youpi> in principle it wouldn't hurt not to, but you'd probably get + surprises + + <phcoder> youpi: would doing EVTCHNOP_reset at the end be enough? + <youpi> possibly, I don't know that one + <youpi> looks like a good thing to do before handing control, indeed + <youpi> /* Clear pending event to avoid unexpected behavior on + re-bind. */ + <youpi> evtchn_port_clear_pending(d1, chn1); + <youpi> yes, it does clear the pending events + <phcoder> http://paste.debian.net/64870/ + <phcoder> I did this: http://paste.debian.net/64871/ + <youpi> well, closing the event channels would be a good idea too + <youpi> (reset does not only clear pending events, it also closes the event + channels) + <phcoder> well we can't close console one. So it leave to close disk ones + (the ones we allocated) + <phcoder> http://paste.debian.net/64875/ + <phcoder> New log: http://paste.debian.net/64876/ (swapon fixed, given 1G + of memory) + <youpi> ok, so it really is something else + <phcoder> looks like there is a space after $(task-resume) but can't tell + if it's real or comes from message + <phcoder> tottally artefact + + <phcoder> youpi: this happens when booted in qemu with old kernel now. Now + my bet is on weird fs corruption or because I accessed it with Linux in + rw. In any case I feel like it's time to call it a port and commit + <youpi> I'd say so, yes + <phcoder> Let's look what's remaining: vfb, vkbd and vif: don't need them + for first port commit. Hm, there is an issue of default configfile. What + is pvgrub default behaviour? + <youpi> iirc it just enters the shell + <youpi> I had implemented vfb and vkbd to get the graphical support, but + that's optional indeed + <youpi> vif is useful for netboot only + <youpi> ah, no, by default it runs dhcp --with-configfile + <phcoder> youpi: port committed to trunk + <youpi> \o/ + <youpi> I was lamenting for 5 years that that wasn't happening :) + <youpi> Citrix could have asked one of his engineers to work on it, really + <phcoder> documentation on using the port is still missing though + <youpi> amazon EC2 users will be happy to upgrade from pv-grub to pv-grub2 + :) + <youpi> I asked some amazon guy at SuperComputing whether he knew how many + people were using pv-grub, but he told me that was customer private + information + <phcoder> Another interesting idea would be to switch between 64-bit and + 32-bit domains somehow + <youpi> yes, we were discussing about it at XenSource when I implemented + pv-grub + <youpi> that's not really an easy thing + <youpi> pvh would probably help there, again + <youpi> in the end, we considered that it was usually not hard to select a + 32bit or 64bit pv-grub depending on the userland bitness + <youpi> we considered adding a hypercall to change the bitness of a domU, + but that's really involved + <phcoder> Well when you discussed i386 domains were still around + <phcoder> now it's only PAE and amd64 and they are very similar. Only few + gdt differ + <youpi> well, switching from 32-PAE to 64 is not *so* hard + <youpi> since a 32bit-loaded OS can fit in 64bit + <youpi> the converse is more questionable of course + <phcoder> yes + <youpi> still, it's really not easy for the hypervisor + <youpi> it'd mean converting stuff here and there + <youpi> most probably missing things here and there :) + <phcoder> Ok, not that important anyway + <youpi> we felt it was too dangerous to promise the feature as working :) + <youpi> heh, 5000 lines patch, just like my patch adding support to Mach :) + <phcoder> BTW do you know how to check if kernel supports dom0 ? Apparently + there is feature "privilegied" and dom0 kernels are supposed to have it + in notes but my linux one doesn't even though I'm in xen now + <youpi> it's XENFEAT_dom0 + <youpi> called dom0 in the notes + <phcoder> http://paste.debian.net/64894/ + <youpi> well, maybe the hypervisor doesn't actually check it's there + <youpi> phcoder: what does grub-mkstandalone? + <phcoder> puts all modules in memdisk which is embed into core + <youpi> ah, ok + <youpi> we didn't have to care about that in grub1 indeed :) + + # Partitions You will need the following notation for the gnumach root= parameter: @@ -108,6 +278,23 @@ You will also need to use the parted storeio module for the /dev entries, for in settrans -fgap /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0 + +## IRC, freenode, #hurd, 2013-11-09 + + <phcoder> youpi: now I get "hd0: dom0's VBD 768 + (/home/phcoder/diskimg/debian-hurd-20130504.img,w) 3001MB" + <phcoder> but "start ext2fs: ext2fs: device:hd0s1: No such device or + address" + <phcoder> disk = [ + 'file:/home/phcoder/diskimg/debian-hurd-20130504.img,hda,w' ] + <phcoder> Hm, using "disk = [ 'phy:loop0,hda1,w' ]" instead worked (loop0 + is an offset loop) + <youpi> yes, xen disks don't support partitioning + <youpi> and we haven't migrated userland to userland partitioning yet + +[[hurd/libstore/part]]. + + # Miscellaneous [[Internals]]. @@ -125,3 +312,20 @@ IRC, freenode, #hurd, 2011-06-08 <braunr> youpi: does xen provide disk caching options ? <youpi> through a blktap, probably <braunr> ok + + +# IRC, freenode, #hurd, 2013-11-09 + + <phcoder> youpi: debian-hurd-20130504.img apparently has a kernel without + xen note. Do I have to do sth special to get xen kernel? + <youpi> phcoder: there's the -xen package for that + <youpi> I haven't made the kernel hybrid + <phcoder> youpi: easiest way is probably to have different entry + points. You could even just link both of them at different addresses and + then glue together though it's not very efficient + <youpi> it's also about all the privileged operations that have to be + replaced with PV operations + <youpi> PVH will help with that regard + + <phcoder> youpi: btw, I recommend compiling xen kernel for 686 and drop + non-pae diff --git a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn index 89a27b01..0ca6d91e 100644 --- a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn +++ b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2010, 2012 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2010, 2012, 2013, 2014 +Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] @@ -130,3 +130,106 @@ further files (also exported ones) that serve no real value, but are being <mcsim> this parameter has name data_count <braunr> that's one of the reasons mach is confusing <braunr> i can't really tell you why, it's messy :/ + + +# [[open_issues/Code_Analysis]], *Coverity* + +## IRC, freenode, #hurd, 2014-02-03 + + <teythoon> braunr: at the end of kmem_cache_error the comment says 'never + reached'. i do not believe that to be true... + <braunr> teythoon: yes, this is a mistake + <braunr> those kmem_error calls were panics in the original version + <braunr> the comment was left over + <braunr> or rather, the panic equivalent not added + + +### IRC, freenode, #hurd, 2014-02-04 + + <teythoon> braunr: but the code relies uppon the fact that kmem_cache_error + does not return + <teythoon> the fact that it doesn't upsets static analysis tools + <teythoon> + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2014-01-17/report-DfjC43.html#Path9 + <braunr> 21:20 < braunr> or rather, the panic equivalent not added + <braunr> teythoon: you're right + <braunr> it needs to be fixed + <teythoon> i setup a coverity project for gnu mach + <teythoon> it's interesting + <teythoon> very enterprisy >,< + <braunr> teythoon: heh + <teythoon> braunr: i assume kmem_error is supposed to panic + <teythoon> if so, i'd propose to use panic instead of printf in that macro + definition + <braunr> yes + <braunr> teythoon: again, that's how it's done in the original + implementation + <teythoon> and fix kmem_cache_error to use kmem_warn near the top of the + function + <braunr> teythoon: i suggest you use the x15 variant as a reference + (http://git.sceen.net/rbraun/x15.git/blob/HEAD:/kern/kmem.c) + <teythoon> right + + +### IRC, OFTC, #debian-hurd, 2014-02-05 + + <pere> ah, cool. <URL: https://scan.coverity.com/projects/1307 > + is now in place. :) + <teythoon> pere: it was you who made me create the coverity project + <teythoon> and it was most fruitful already + <pere> glad to hear that. :) + <pere> while the mach thread made me discover scan-build, which + seem promising but have way to few rules. + <pere> teythoon: btw, could I get access to the mach coverity + status? + <teythoon> pere: sure + <pere> I've used up all my 'join project' slots, so I suspect you + have to invite me. try pere@hungry.com + <teythoon> pere: ok + <teythoon> pere: i'm fuzzy about the roles + <teythoon> what kind of invite shall i send you ? + <pere> not sure either. + <teythoon> ok + <pere> contributor/* would be fine for me. want to check the + details, not just the overview. + <teythoon> oh + * pere looked up the role description + <teythoon> do you have a link ? + <teythoon> i can always change the role afaics + <pere> go to the member list, found it there. + <pere> (the link is project specific, it seem. + <teythoon> right, found it + <pere> gah, it gave me a new user. :( + <pere> I assumed I would be allowed to accept the invite using my + normal user. + <pere> can you try again with pere-github@hungry.com, which + hopefully will hook the invite to my github authenticated user? + <teythoon> sure + <pere> were you allowed to invite that address? + <pere> ah, I got it in my dashboard without having to do anything + more. + <pere> heh, the email I got claimed the user would not be created + unless I provided a password, but given the member list for mach, + I fail to see how that could be true. + + +### IRC, OFTC, #debian-hurd, 2014-02-06 + + <teythoon> pere: your coverity invitations are still saying 'not + accepted', did neither work ? + <pere> teythoon: one worked just fine. I got access. the other I + did not accept. + <teythoon> pere: good :) + + +### IRC, OFTC, #debian-hurd, 2014-02-25 + + <pere> I am quite impressed with the defect density of Mach, <URL: + https://scan.coverity.com/projects/1307 >. :) + <pere> 12 outstanding issues (but 54 dismissed was surprisingly + high :). + <youpi> pere: 54 dismissed because that's a pattern generated by + mig + <youpi> repeated dozens of times + +[[!tag open_issue_mig]] |