On Di, 16.03.21 14:13, Christoph Hellwig (h...@infradead.org) wrote:
> On Mon, Mar 15, 2021 at 08:18:24PM +, Matthew Wilcox wrote:
> > On Mon, Mar 15, 2021 at 09:02:38PM +0100, Matteo Croce wrote:
> > > From: Matteo Croce
> > >
> > > Add a sequence number to the disk devices. This number is
seqnos, as
mentioned in that other mail.
But beggars can't be choosers. If we could propagate some uuid from
the loopback setup ioctl into the device so that that appears via
sysfs that would work too for me, but not as robustly, since we lack
the ordering to detect whether it's worth waiting f
t would make sense to bump the IDs not only on
explicit user-induced reattachments, but also when media is replaced,
i.e. bump it more often than not)
Lennart
--
Lennart Poettering, Berlin
h
an approach where userspace can pick the ids, too. I'll take what I
can get. My primary concern is that we get something to match up
uevents, partition devices and the main block device with, and all of
the suggested approaches could deliver that.
Lennart
--
Lennart Poettering, Berlin
On Sa, 06.02.21 01:08, Matteo Croce (mcr...@linux.microsoft.com) wrote:
> From: Matteo Croce
>
> With this series a monotonically increasing number is added to disks,
> precisely in the genhd struct, and it's exported in sysfs and uevent.
>
> This helps the userspace correlate events for devices
rotected?
>
> i thought mprotect(PROT_EXEC) would get filtered
> with or without bti, is that not the case?
We can adjust the filter in systemd to match any combination of
flags to allow and to deny.
Lennart
--
Lennart Poettering, Berlin
t me know.
[An acceptable compromise might be to allow
mprotect(PROT_EXEC|PROT_BTI) if MDWE is on, but prohibit
mprotect(PROT_EXEC) without PROT_BTI. Then at least you get one of the
two protections, but not both. I mean, MDWE is not perfect anyway on
non-x86-64 already: on 32bit i386 MDWE prote
with this: it's a bit weird to alter the bits after
the fact. Can't glibc set up everything right from the begining? That
would keep both concepts working.
Lennart
--
Lennart Poettering, Berlin
Hi!
Even with fe6a8fc5ed2f0081f17375ae2005718522c392c6 the LOOP_CONFIGURE
ioctl doesn't work correctly. It gets confused if the
lo_offset/lo_sizelimit fields are set to non-zero.
In a quick test I ran (on Linux 5.8.3) I call LOOP_CONFIGURE with
.lo_offset=3221204992 and .lo_sizelimit=50331648
because the kernel doesn't expose that at all right now.
OTOH I'd already be quite happy if struct statfs64 would expose
f_features, f_max_fsize, f_time_granularity, f_charset_case_handling
fields or so.
Lennart
--
Lennart Poettering, Berlin
ome
fields we'd know afterwards that the fields were filled in together
and are congruent with each other.
I am a fan of the statx() system call I must say. If we had something
like this for the file system itself I'd be quite happy, it could tick
off many of the requests I list above.
Hope this is useful,
Lennart
--
Lennart Poettering, Berlin
group/" (because that's where cgroupfs is mounted), of "/"
(i.e. for the root cgroup) and of "/cgroup.controllers" (as that's the
file the attribute is exposed under).
And there you go:
"/sys/fs/cgroup/" + "/" + "/cgroup.controllers" →
"/sys/fs/cgroup///cgroup.controllers"
This is a real-life thing. Don't break this please.
Lennart
--
Lennart Poettering, Berlin
it works fine with LOOP_SETSTATUS.
Let's correct that and propagate the flag in LOOP_CONFIGURE too.
Fixes: 3448914e8cc5("loop: Add LOOP_CONFIGURE ioctl")
Signed-off-by: Lennart Poettering
Acked-by: Martijn Coenen
---
drivers/block/loop.c | 2 ++
1 file changed, 2 insertions(+)
On Fr, 07.08.20 10:53, Martijn Coenen (m...@android.com) wrote:
> Hi Lennart,
>
> Thanks again for the patch, I tested it and it looks good to me. I'll
> also add a test case to LTP for this. Two minor nits on the patch:
>
> On Thu, Aug 6, 2020 at 9:32 AM Lennart Poettering
it works fine with LOOP_SETSTATUS.
Let's correct that and propagate the flag in LOOP_SETSTATUS too.
Signed-off-by: Lennart Poettering
---
drivers/block/loop.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index d18160146226..2f137d6ce169 100644
On Fr, 27.09.19 08:58, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Fri, Sep 27, 2019 at 6:57 AM Lennart Poettering
> wrote:
> >
> > Doing the random seed in the boot loader is nice for two reasons:
> >
> > 1. It runs very very early, so that
latform
> AT ALL, we can trust that". Since you can't reasonably do things like
> add EFI variables to your distro image by mistake.
NVRAM backing EFI vars sucks. Nothing you want to update on every
cycle. It's OK to update during OS installation, but during every
single boot? I'd rather not.
Lennart
--
Lennart Poettering, Berlin
to say this all differently: the hash table seeding and the uuid
case are two distinct cases in systemd, and I am sure they should be.
Lennart
--
Lennart Poettering, Berlin
l
> (even without trusting it completely)?)
Neither RDRAND nor /dev/urandom know a concept of "depleting
entropy". That concept does not exist for them. It does exist for
/dev/random, but only crazy people use that. systemd does not.
Lennart
--
Lennart Poettering, Berlin
o make them
credit entropy. I am pretty sure this should be the default now, in a
world where CONFIG_RANDOM_TRUST_CPU=y is set anyway. i.e. why say
RDRAND is fine but those chipsets are not? That makes no sense to me.
I am very sure that crediting entropy to chipset hwrngs is a much
better way to so
On Di, 17.09.19 09:23, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Tue, Sep 17, 2019 at 9:08 AM Lennart Poettering
> wrote:
> >
> > Here's what I'd propose:
>
> So I think this is ok, but I have another proposal. Before I post that
> one, though,
pool is initialized it's
initialized. This means any pending getrandom() on the whole system
will unblock at the same time, and from the on all getrandom()s will
be non-blocking.
systemd-random-seed.service is nowadays a synchronization point for
exactly the moment where the pool is considered fu
256 is the only
sane range for cryptographic keys...
Lennart
--
Lennart Poettering, Berlin
On Di, 17.09.19 18:21, Willy Tarreau (w...@1wt.eu) wrote:
> On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering wrote:
> > Note that calling getrandom(0) "too early" is not something people do
> > on purpose. It happens by accident, i.e. because we live in a wor
On Di, 17.09.19 12:30, Ahmed S. Darwish (darwish...@gmail.com) wrote:
> Ideally, systems would be configured with hardware random
> number generators, and/or configured to trust the CPU-provided
> RNG's (CONFIG_RANDOM_TRUST_CPU) or boot-loader provided ones
>
On Di, 17.09.19 08:11, Theodore Y. Ts'o (ty...@mit.edu) wrote:
> On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> > Willy Tarreau - 17.09.19, 07:24:38 CEST:
> > > On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> > > > >Well, the patch actually made
On Mo, 16.09.19 13:21, Theodore Y. Ts'o (ty...@mit.edu) wrote:
> We could create a new flag, GRND_INSECURE, which never blocks. And
> that that allows us to solve the problem for silly applications that
> are using getrandom(2) for non-cryptographic use cases. Use cases
> might include Python
quot; time).
As mentioned, in systemd's case, updating the random seed on disk
is entirely fine to take 5h or so. I don't really think we really need
to bound this in kernel space.
Lennart
--
Lennart Poettering, Berlin
case, I am sure.
Quite frankly, I don't think this is something to fix in the
kernel. Let the people putting together systems deal with this. Let
them provide a creditable hw rng, and let them pay the price if they
don't.
Lennart
--
Lennart Poettering, Berlin
On So, 15.09.19 09:27, Ahmed S. Darwish (darwish...@gmail.com) wrote:
> On Sun, Sep 15, 2019 at 08:51:42AM +0200, Lennart Poettering wrote:
> > On Sa, 14.09.19 09:30, Linus Torvalds (torva...@linux-foundation.org) wrote:
> [...]
> >
> > And please don't break /dev/urand
the boot will block, yes.
Basically, just add "nofail" to a line in /etc/crypttab, and the entry
will be activated at boot, but we won't delay boot for it. It's going
to be activated as soon as the deps are fulfilled (and thus the pool
initialized), but that may well be 5h after boot, an
On So, 15.09.19 09:01, Willy Tarreau (w...@1wt.eu) wrote:
> On Sun, Sep 15, 2019 at 08:56:55AM +0200, Lennart Poettering wrote:
> > There's benefit in being able to wait until the pool is initialized
> > before we update the random seed stored on disk with a new one,
>
> A
wait until the pool is initialized
before we let cryptsetup read a fresh, one-time key for dm-crypt from
/dev/urandom. I fully understand that any such reporting for
initialization is "best-effort", i.e. to the point where we don't know
anything to the contrary, but at least give userspace that.
Lennart
--
Lennart Poettering, Berlin
On Sa, 14.09.19 09:30, Linus Torvalds (torva...@linux-foundation.org) wrote:
> > => src/random-seed/random-seed.c:
> > /*
> > * Let's make this whole job asynchronous, i.e. let's make
> > * ourselves a barrier for proper initialization of the
> > * random pool.
> > */
On Mi, 14.08.19 11:32, Alexandre Belloni (alexandre.bell...@bootlin.com) wrote:
> On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> >
> > > - glibc stops passing the caller timezone argument to the k
n its own without
involving userspace in that.
Lennart
--
Lennart Poettering, Berlin
est option for systemd and it's only one
> system call.
That doesn't really work for us as readlink() on that requires
CAP_SYS_PTRACE, and we need something that works unprivileged, which
PF_KTHREAD does.
Lennart
--
Lennart Poettering, Red Hat
est option for systemd and it's only one
> system call.
That doesn't really work for us as readlink() on that requires
CAP_SYS_PTRACE, and we need something that works unprivileged, which
PF_KTHREAD does.
Lennart
--
Lennart Poettering, Red Hat
On Wed, 28.06.17 09:06, Luis R. Rodriguez (mcg...@kernel.org) wrote:
> On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering
> <mzxre...@0pointer.de> wrote:
> > On Wed, 28.06.17 00:24, Luis R. Rodriguez (mcg...@kernel.org) wrote:
> >
> >> > Do you know how sys
On Wed, 28.06.17 09:06, Luis R. Rodriguez (mcg...@kernel.org) wrote:
> On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering
> wrote:
> > On Wed, 28.06.17 00:24, Luis R. Rodriguez (mcg...@kernel.org) wrote:
> >
> >> > Do you know how systemd developers feel
t external.
Certainly not. I'd sure know about that. ;-)
Lennart
--
Lennart Poettering, Red Hat
t external.
Certainly not. I'd sure know about that. ;-)
Lennart
--
Lennart Poettering, Red Hat
t's not supposed to be a work-around around broken
input drivers.
I am very sure that input drivers shouldn't lie to userspace. If you
don't know the state of the switch, then you don#t know it, and should
clarify that to userspace somehow.
Lennart
--
Lennart Poettering, Red Hat
t's not supposed to be a work-around around broken
input drivers.
I am very sure that input drivers shouldn't lie to userspace. If you
don't know the state of the switch, then you don#t know it, and should
clarify that to userspace somehow.
Lennart
--
Lennart Poettering, Red Hat
bug, and it should not be handled by the kernel
> community.
Uh if this is borked, we should indeed fix this in systemd. Is there
already a systemd github bug about this? If not, please create one,
and we'll look into it!
Thanks for working on this,
Lennart
--
Lennart Poettering, Red Hat
bug, and it should not be handled by the kernel
> community.
Uh if this is borked, we should indeed fix this in systemd. Is there
already a systemd github bug about this? If not, please create one,
and we'll look into it!
Thanks for working on this,
Lennart
--
Lennart Poettering, Red Hat
On Mon, 01.12.14 14:54, Dave Chinner (da...@fromorbit.com) wrote:
> On Mon, Dec 01, 2014 at 02:03:43AM +0100, Lennart Poettering wrote:
> > On Mon, 01.12.14 01:41, Richard Weinberger (rich...@nod.at) wrote:
> >
> > > CC'ing systemd folks.
> > >
> > > Le
On Mon, 01.12.14 14:54, Dave Chinner (da...@fromorbit.com) wrote:
On Mon, Dec 01, 2014 at 02:03:43AM +0100, Lennart Poettering wrote:
On Mon, 01.12.14 01:41, Richard Weinberger (rich...@nod.at) wrote:
CC'ing systemd folks.
Lennart, can you please explain why you need
On Mon, 01.12.14 01:41, Richard Weinberger (rich...@nod.at) wrote:
> CC'ing systemd folks.
>
> Lennart, can you please explain why you need CONFIG_FHANDLE for systemd?
> Maybe I'm reading the source horrible wrong.
For two usecases:
a) Being able to detect if something is a mount point. The
On Mon, 01.12.14 01:41, Richard Weinberger (rich...@nod.at) wrote:
CC'ing systemd folks.
Lennart, can you please explain why you need CONFIG_FHANDLE for systemd?
Maybe I'm reading the source horrible wrong.
For two usecases:
a) Being able to detect if something is a mount point. The
rspace
daemons can subscribe to that and then refresh the DHCP leases on their
own.
Lennart
--
Lennart Poettering, Red Hat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
to that and then refresh the DHCP leases on their
own.
Lennart
--
Lennart Poettering, Red Hat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
ried both just running it and also running exec foo; both presented
> the same issue given that shell exec does not really execve.
Hmmm? You shell's "exec" command doesn't actually execve()? What are you
using? This doesn't sound very accurate...
Lennart
--
Lennart Poettering, Red Hat
On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcg...@suse.com) wrote:
> On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> > On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@suse.com) wrote:
> >
> > > I'm cc'ing a few security folks as I'd apprec
On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcg...@suse.com) wrote:
On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@suse.com) wrote:
I'm cc'ing a few security folks as I'd appreciate review on the ideas
here
foo; both presented
the same issue given that shell exec does not really execve.
Hmmm? You shell's exec command doesn't actually execve()? What are you
using? This doesn't sound very accurate...
Lennart
--
Lennart Poettering, Red Hat
--
To unsubscribe from this list: send the line unsubscribe
ust
want to execute on ot another program...
That said, I'd certainly make a clean cut and drop support for
/etc/sysconfig from any project I see, earlier rather than later, since
it's just cruft, a bad idea and should really just go away. But then
again, I would also just not do the thing wit
for
/etc/sysconfig from any project I see, earlier rather than later, since
it's just cruft, a bad idea and should really just go away. But then
again, I would also just not do the thing with supporting two
implementations at the same time...
Lennart
--
Lennart Poettering, Red Hat
articularly messy if you intend to share devices
between containers.
> > logind can do this for you between sessions. But such a container setup
> > will never work without proper device namespacing.
>
> So how can it do it when there is no kernel support? You mean it could
> be doing this
ic device at a specific moment
Well, there's no point in inventing any "mechanisms" like this, as long
as devices are not namespaced in the kernel, so that userspace in
containers can enumerate/probe/identify/... things correctly...
Lennart
--
Lennart Poettering, Red Hat
--
To unsubscrib
are not namespaced in the kernel, so that userspace in
containers can enumerate/probe/identify/... things correctly...
Lennart
--
Lennart Poettering, Red Hat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
proper device namespacing.
So how can it do it when there is no kernel support? You mean it could
be doing this if the support were there?
EVIOCREVOKE and the DRM ioctls are pretty real...
Lennart
--
Lennart Poettering, Red Hat
--
To unsubscribe from this list: send the line unsubscribe
te changelog he had.
>
> He also fails to explain why he needs the timestamp twice, as do you for
> that matter.
Well, I am mostly interesting int the monotonic timestamp. But given
that the kernel keeps the boottime clock value as well, and already
exposes it in a skewed way to us
On Wed, 22.01.14 16:53, Peter Zijlstra (pet...@infradead.org) wrote:
>
> On Tue, Jan 21, 2014 at 07:10:04AM -0800, Dan Ballard wrote:
> > starttime in /proc/$PID/stat is inaccurate by "clock tick" granularity.
> > The kernel keeps better track os this exposes that in /prod/$PID/status
> > as
On Wed, 22.01.14 16:53, Peter Zijlstra (pet...@infradead.org) wrote:
On Tue, Jan 21, 2014 at 07:10:04AM -0800, Dan Ballard wrote:
starttime in /proc/$PID/stat is inaccurate by clock tick granularity.
The kernel keeps better track os this exposes that in /prod/$PID/status
as
. But given
that the kernel keeps the boottime clock value as well, and already
exposes it in a skewed way to userspace it looked like a natural choice
to also expose that time in a clean way, while we are it...
Lennart
--
Lennart Poettering, Red Hat
--
To unsubscribe from this list: send the line
On Mon, 14.10.13 15:48, Matthew Garrett (matthew.garr...@nebula.com) wrote:
> On Mon, 2013-10-14 at 17:36 +0200, Lennart Poettering wrote:
>
> > Sorry, still not getting this. How should this ever work if the intel
> > video driver is compiled as kmod? That means that it
ight if the intel
driver is compiled will be an entirely pointless excercise on all
distros?
What am I missing?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
I missing?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
On Mon, 14.10.13 15:48, Matthew Garrett (matthew.garr...@nebula.com) wrote:
On Mon, 2013-10-14 at 17:36 +0200, Lennart Poettering wrote:
Sorry, still not getting this. How should this ever work if the intel
video driver is compiled as kmod? That means that it isn't clear at all
when
on
of the acpi backlight device if the "raw" device is supported? I mean,
the intel driver could be compiled as a module (and generally is on the
popular distros), so at the time the ACPI subsystem wants to register
the backlight device and know if a raw backlight device is around it
never will be,
also blacklists the thing in the
ideapad driver, so that only the intel backlight driver is enabled on
Yoga 13 systems, at which point everything will work fine.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
="!Windows 2012" on the kernel command line. It appears that
backlight control via the EC simply is not available at all, regardless
whether done via ACPI or via the vendor driver.
Signed-off-by: Lennart Poettering
---
drivers/acpi/video_detect.c | 8
1 file changed, 8 insertions(+)
=!Windows 2012 on the kernel command line. It appears that
backlight control via the EC simply is not available at all, regardless
whether done via ACPI or via the vendor driver.
Signed-off-by: Lennart Poettering lenn...@poettering.net
---
drivers/acpi/video_detect.c | 8
1 file changed, 8
fine.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
subsystem wants to register
the backlight device and know if a raw backlight device is around it
never will be, so what is the point of that? Or am I missing something?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
fine. That's what the virtualization
folks did with their hypervisor consoles, and is what we required from
the container folks too.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
onsoles makes no sense.
> (Same like on s390)
You are aware that turning off the tty subsystem in the kernel is
something different than turning off the virtual console? Note that the
whole stuff is really confusingly named, as /dev/tty1 is genericly named
"tty", even if it actually refer
and nothing else.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
folks too.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
mething). Can we do something about the situation? Can we remove
> >> /dev/tty*, and provide /dev/hvc*? Will we be breaking existing users?
> >>
> >> Thanks.
> >>
> >> Lennart Poettering wrote:
> >>> UML shouldn't be penalized for not
users?
Thanks.
Lennart Poettering wrote:
UML shouldn't be penalized for not implementing some terminal emulation,
but it should be penalized for doing so under the label of VT support,
which it simply is not providing.
They can call their ttys any way they want. If the call them
Heya,
On 29.06.2013 05:05, Tim Hockin wrote:
Come on, now, Lennart. You put a lot of words in my mouth.
I for sure am not going to make the PID 1 a client of another daemon. That's
just wrong. If you have a daemon that is both conceptually the manager of
another service and the client of
Heya,
On 29.06.2013 05:05, Tim Hockin wrote:
Come on, now, Lennart. You put a lot of words in my mouth.
I for sure am not going to make the PID 1 a client of another daemon. That's
just wrong. If you have a daemon that is both conceptually the manager of
another service and the client of
On 28.06.2013 20:53, Tim Hockin wrote:
a single-agent, we should make a kick-ass implementation that is
flexible and scalable, and full-featured enough to not require
divergence at the lowest layer of the stack. Then build systemd on
top of that. Let systemd offer more features and policies
On 28.06.2013 20:53, Tim Hockin wrote:
a single-agent, we should make a kick-ass implementation that is
flexible and scalable, and full-featured enough to not require
divergence at the lowest layer of the stack. Then build systemd on
top of that. Let systemd offer more features and policies
ference? I'd
still call this "Boot and Core OS MC" as this has the slightler broader
topic, I guess...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
one clue me in to the microconference format as regards LPC?
BTW, there's also this MC we proposed:
http://wiki.linuxplumbersconf.org/2013:boot_and_core_os
which sounds pretty close to fastboot?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubsc
pretty close to fastboot?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
ng and then
split it up again. It sounds much more sensible to instead just pass the
string array around all the time. What's the reason to make this one
string first?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
and I am not sure it worth the trouble.
It sounds really wrong to first merge this into one string and then
split it up again. It sounds much more sensible to instead just pass the
string array around all the time. What's the reason to make this one
string first?
Lennart
--
Lennart Poettering - Red
Heya,
On 08.04.2013 15:46, Glauber Costa wrote:
On 04/06/2013 05:21 AM, Tejun Heo wrote:
Hello, guys.
Hello Tejun, how are you?
Status-quo
==
tl;did read;
This is mostly sensible. There is still one problem that we hadn't yet
had the bandwidth to tackle that should be added
Heya,
On 08.04.2013 15:46, Glauber Costa wrote:
On 04/06/2013 05:21 AM, Tejun Heo wrote:
Hello, guys.
Hello Tejun, how are you?
Status-quo
==
tl;did read;
This is mostly sensible. There is still one problem that we hadn't yet
had the bandwidth to tackle that should be added
Heya,
(sorry for the late reply)
On 16.08.2012 22:00, Tejun Heo wrote:
On Thu, Aug 16, 2012 at 01:44:56PM -0400, a...@redhat.com wrote:
Attaching meta information to services, in an easily discoverable
way. For example, in systemd we create one cgroup for each service, and
could then store
Heya,
(sorry for the late reply)
On 16.08.2012 22:00, Tejun Heo wrote:
On Thu, Aug 16, 2012 at 01:44:56PM -0400, a...@redhat.com wrote:
Attaching meta information to services, in an easily discoverable
way. For example, in systemd we create one cgroup for each service, and
could then store
sure it
is paged in before I pass it on to the RT thread. So, there's a
mmap() during startup only, and then, during the whole runtime of my
program I want to page in the memory again and again, with long
intervals in between, but with no call to mmap()/munmap().
Lennart
--
Lennart Poettering
it on to the RT thread. So, there's a
mmap() during startup only, and then, during the whole runtime of my
program I want to page in the memory again and again, with long
intervals in between, but with no call to mmap()/munmap().
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart
the single
difference that RLIMIT_CPU sends out a signal depending on the total
CPU time used for the process and the new RLIMIT based on the time the
process spent without sleeping. That would be a very reasonable
extension to the current RLIMIT_CPU model.
Thank you very much for doing this patch!
Lennart
-
sends out a signal depending on the total
CPU time used for the process and the new RLIMIT based on the time the
process spent without sleeping. That would be a very reasonable
extension to the current RLIMIT_CPU model.
Thank you very much for doing this patch!
Lennart
--
Lennart Poettering
1 - 100 of 108 matches
Mail list logo
