diff options
Diffstat (limited to 'microkernel/mach/gnumach/interface')
3 files changed, 140 insertions, 2 deletions
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/interface/task_set_name.mdwn b/microkernel/mach/gnumach/interface/task_set_name.mdwn new file mode 100644 index 00000000..c32a24ff --- /dev/null +++ b/microkernel/mach/gnumach/interface/task_set_name.mdwn @@ -0,0 +1,22 @@ +[[!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 +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]]."]]"""]] + +/!\ Does this actually reflect reality? + +[[!tag open_issue_documentation open_issue_gnumach]] + +A `task_set_name` RPC has been added to GNU Mach. Before, the Mach debugger +looked for `arg[0]` on the stack using ugly heuristics (see +`gnumach/i386/i386/db_interface.c`, `looks_like_command`...). Now we can let +`exec` simply set the name and record it in `task_t`. After adding the RPC, +glibc needs to be recompiled against the updated `mach.defs` to get access to +it from userland, and exec would probably call it from `hurd/exec/exec.c`, +`do_exec()`. Also see the discussion on +[[open_issues/translate_fd_or_port_to_file_name]]. |