* device/dk_label.c: Remove file.
---
device/dk_label.c | 99 ---
1 file changed, 99 deletions(-)
delete mode 100644 device/dk_label.c
diff --git a/device/dk_label.c b/device/dk_label.c
deleted file mode 100644
index c7d459b..000
--- a/dev
* device/dev_pager.c [lint]: Remove ifdefs and associated code.
---
device/dev_pager.c | 12
1 file changed, 12 deletions(-)
diff --git a/device/dev_pager.c b/device/dev_pager.c
index a1b9eb9..63726b6 100644
--- a/device/dev_pager.c
+++ b/device/dev_pager.c
@@ -331,10 +331,6 @@ kern
* device/dev_pager.c: Coding style changes.
---
device/dev_pager.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/device/dev_pager.c b/device/dev_pager.c
index 7f49805..a1b9eb9 100644
--- a/device/dev_pager.c
+++ b/device/dev_pager.c
@@ -262,12
* device/dev_pager.c: Coding style changes.
---
device/dev_pager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/device/dev_pager.c b/device/dev_pager.c
index 63726b6..da6ec7e 100644
--- a/device/dev_pager.c
+++ b/device/dev_pager.c
@@ -186,7 +186,7 @@ void dev_pager_has
What follows is a small cleanup of the device pager. The majority
of casts are done without whitespace, so in patches 2 and 4 I
modified the rest to follow this rule. I'm guessing that lint
is not used anymore, so in patch 3 I suggest the removal of the
associated ifdefs and code.
[PATCH 1/4] remo
* device/dev_pager.c: Remove register qualifiers.
---
device/dev_pager.c | 58 +++---
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/device/dev_pager.c b/device/dev_pager.c
index e0ca2c7..7f49805 100644
--- a/device/dev_pager.c
+++
Hi :)
ok, getting back on topic:
Quoting Thomas Schwinge (2013-09-10 20:36:42)
> > /hurd/init is not an init system, it barely does anything any other
> > init system does. From my point of view its name is the only thing
> > that it has in common with other init systems, and it should really be
* Makefrag.am: Add task_notify.defs.
* include/mach/gnumach.defs: Add register_new_task_notification.
* include/mach/task_notify.defs: New file.
* kern/task.c (new_task_notification): New variable.
(task_create): Send new task notifications.
(register_new_task_notification): Add server function.
*
XXX
---
init/Makefile |2 +-
init/init.c | 87 +
2 files changed, 33 insertions(+), 56 deletions(-)
diff --git a/init/Makefile b/init/Makefile
index ffb82ff..cf4d492 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -23,7 +23,7 @@ OB
XXX
* hurd/process_notify.defs: New file.
---
hurd/process_notify.defs | 21 +
1 file changed, 21 insertions(+)
create mode 100644 hurd/process_notify.defs
diff --git a/hurd/process_notify.defs b/hurd/process_notify.defs
new file mode 100644
index 000..7972ef7
--- /dev
* proc/Makefile: XXX add gnumach stubs.
* proc/main.c (message_demuxer): Add task_notify_server.
(main): Register for new task notificatinos.
(main): Get all tasks created prior to registering the notifications.
* proc/mgt.c (S_mach_notify_new_task): Add server function.
---
proc/Makefile |5 +
---
init/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/init/Makefile b/init/Makefile
index cf4d492..fc2a647 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -21,7 +21,7 @@ makemode := server
SRCS = init.c stubs.c
OBJS = $(SRCS:.c=.o) \
startupServer.o n
XXX
* hurd/process.defs: Add proc_request_process_change_notification.
---
hurd/process.defs |6 ++
1 file changed, 6 insertions(+)
diff --git a/hurd/process.defs b/hurd/process.defs
index bf90556..565d8bf 100644
--- a/hurd/process.defs
+++ b/hurd/process.defs
@@ -400,3 +400,9 @@ routine
XXX
XXX
---
proc/Makefile |5 +++--
proc/main.c |3 +++
proc/mgt.c| 35 +++
proc/proc.h |6 ++
4 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/proc/Makefile b/proc/Makefile
index 2eed13c..97d9077 100644
--- a/proc/Makefile
XXX
---
libhurdnotify/Makefile | 28 ++
libhurdnotify/notify.c | 251
libhurdnotify/notify.h | 73 ++
3 files changed, 352 insertions(+)
create mode 100644 libhurdnotify/Makefile
create mode 100644 libhurdnotify/notify.c
crea
Hi :)
this mail discusses my recent attempts of creating a cgroupfs, related
problems and issues I encountered so far.
Problem statement
=
Linux has this feature called cgroups. It groups processes (threads)
together in groups, furthermore so called controllers can be used to
res
On Mon, Sep 16, 2013 at 02:22:51PM +0200, Samuel Thibault wrote:
> Well, then it can be done by something else than the proc server, it
> does not really matter much. What matters is that we don't want to let
> user tasks leak tasks without some control.
In my opinion, since tasks are kernel obje
Ludovic Courtès, le Mon 16 Sep 2013 14:03:50 +0200, a écrit :
> Samuel Thibault skribis:
>
> > Ludovic Courtès, le Mon 16 Sep 2013 12:34:37 +0200, a écrit :
> >> Samuel Thibault skribis:
> >>
> >> > Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
> >> >> On Thu, Sep 12, 2013 at 10:3
On Mon, Sep 16, 2013 at 02:58:24AM +0200, Richard Braun wrote:
> On Mon, Sep 16, 2013 at 01:50:57AM +0200, Samuel Thibault wrote:
> > Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
> > > I suggest we simply disable the trap versions.
> >
> > Ah, right.
> >
> > I don't have the time t
Samuel Thibault skribis:
> Ludovic Courtès, le Mon 16 Sep 2013 12:34:37 +0200, a écrit :
>> Samuel Thibault skribis:
>>
>> > Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
>> >> On Thu, Sep 12, 2013 at 10:38:31AM +0200, Samuel Thibault wrote:
>> >> > Richard Braun, le Thu 12 Sep 20
On Mon, Sep 16, 2013 at 12:41:19PM +0200, Samuel Thibault wrote:
> Justus Winter, le Mon 16 Sep 2013 12:20:24 +0200, a écrit :
> > Richard asked me to make /hurd/proc run with a PID other than 0
> > because that causes various problems.
>
> What kind of problem for instance? (at least for the reco
Quoting Samuel Thibault (2013-09-16 12:41:19)
> Justus Winter, le Mon 16 Sep 2013 12:20:24 +0200, a écrit :
> > Richard asked me to make /hurd/proc run with a PID other than 0
> > because that causes various problems.
>
> What kind of problem for instance? (at least for the record)
http://darnass
Ludovic Courtès, le Mon 16 Sep 2013 12:34:37 +0200, a écrit :
> Samuel Thibault skribis:
>
> > Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
> >> On Thu, Sep 12, 2013 at 10:38:31AM +0200, Samuel Thibault wrote:
> >> > Richard Braun, le Thu 12 Sep 2013 10:33:23 +0200, a écrit :
> >>
Justus Winter, le Mon 16 Sep 2013 12:20:24 +0200, a écrit :
> Richard asked me to make /hurd/proc run with a PID other than 0
> because that causes various problems.
What kind of problem for instance? (at least for the record)
Samuel
Samuel Thibault skribis:
> Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
>> On Thu, Sep 12, 2013 at 10:38:31AM +0200, Samuel Thibault wrote:
>> > Richard Braun, le Thu 12 Sep 2013 10:33:23 +0200, a écrit :
>> > > Then why are we discussing interposing system calls ?
>> >
>> > Becau
Justus Winter, le Mon 16 Sep 2013 10:42:00 +0200, a écrit :
> Tbh I don't know anymore, but I must have encountered it on one of my
> machines. I guess it's possible to use ext2fs ... -T device hd0s1.
Ok. That's really why I'd prefer to see ext2fs etc. actually provide a
get_source hook, to avoid
Using PID 0 is problematic for various reasons. Make /hurd/proc run as
PID 3 instead.
* include/pids.h: Make /hurd/proc PID 3.
---
include/pids.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/pids.h b/include/pids.h
index 485916b..22415f4 100644
--- a/include/pids
Hi ;)
Richard asked me to make /hurd/proc run with a PID other than 0
because that causes various problems. I fully agree. Fortunately the
fix is straight forward.
Justus
Using PID 0 causes various problems. This makes genpid skip PID 0.
* proc/mgt.c (genpid): Start PIDs at 1.
---
proc/mgt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/proc/mgt.c b/proc/mgt.c
index c093b8f..d7ad296 100644
--- a/proc/mgt.c
+++ b/proc/mgt.c
@@ -862,7 +862,7
Quoting Samuel Thibault (2013-09-15 23:27:58)
> Justus Winter, le Tue 30 Jul 2013 11:59:24 +0200, a écrit :
> > + if (strncmp (device, "device:", 7) == 0)
> > +asprintf (path, "/dev/%s", &device[7]);
> > + else if (strncmp (device, "/dev/", 5) == 0)
> > +*path = strdup (device);
>
> > +
On 16.09.2013 09:38:35, Samuel Thibault wrote:
> Marin Ramesa, le Mon 16 Sep 2013 08:30:44 +0200, a écrit :
> > Actually, it changes the behavior when the values at the memory
> > locations beyond null-termination are equal.
Sorry. The other version does this. It's what I intented.
> Err, but th
Marin Ramesa, le Mon 16 Sep 2013 08:30:44 +0200, a écrit :
> Actually, it changes the behavior when the values at the memory
> locations beyond null-termination are equal.
Err, but the added lines do not break the loop at the null-termination,
so I still don't understand what changes.
Samuel
Marin Ramesa, le Mon 16 Sep 2013 08:09:44 +0200, a écrit :
> Yes, but the const protects the copy. It expresses the intent of the
> function. It's like saying to the caller: "I will behave nicely and not
> modify the passed value during my execution." Then the caller knows
> that the value of th
33 matches
Mail list logo