Re: [systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

[Michael Olbrich]

On Fri, Aug 01, 2014 at 06:37:51PM +0300, Samuli Suominen wrote:
> On 01/08/14 18:31, Simon McVittie wrote:
> > On 01/08/14 15:53, Simon McVittie wrote:
> >> Best-practice in Autotools projects seems to be to include config.h at
> >> the very top of every .c file, whether it is currently needed or not.
> > Sorry, I'd missed that systemd uses "cc -include
> > $(top_builddir)/config.h ...", which is even better. My issues with
> > btrfs_ioctl_vol_args must have been caused by something else.
> >
> 
> nod. I've just tested the original patch I posted, seems to work here...
> I suppose it's best to apply the initlal patch first, and see if someone
> gets a failed build...

is HAVE_LINUX_BTRFS_H defined for you? I've tried the same thing, and it
failed for me, but only with old kernel headers without linux/btrfs.h

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Support for pre-restart check

[Reindl Harald]

please don't break "reply-to-list" with reply-all

Am 31.07.2014 um 13:30 schrieb Mantas Mikulėnas:
> On Jul 31, 2014 12:57 PM, "Reindl Harald"  > wrote:
>> Am 31.07.2014 um 02:16 schrieb Colin Guthrie:
>> > Reindl Harald wrote on 30/07/14 13:34:
>> >> *how* should that both help in calling "apachectl -t" *before* stop the
>> >> service and in case of a error-repsonse keep it running?
>> >
>> > Note, just for clarity, you don't really want to run such a config test
>> > when explicitly stopping a service
>>
>> i do want that in case it ends in a state where i can't start it afterwards
>> "systemctl stop X && rsync data; systemctl start X" and go to a coffee is
>> not that uncommon
> 
> What if the configuration is fine in the beginning, but another admin breaks 
> it while your rsync is running?

then *really* shit happens - that you can't catch all cases don't
mean you should not try to catch the possible ones

normally one does a hot rsync while service is up, stop the service
followed by a cold rsync and start the service - so the time window
is very short even if your dataset is gigabytes large

anyways, it makes no sense to discuss about each and every possible
case on the world - i only pointed out "you don't really want" is
not true, anything else is the responsibility of the admin and
depends stronly on the environemnt and usecase

we talk about *options* here and the correct usecase is out of scope
if you want to find arguments against something you will always find
one like "ExecReload=/usr/bin/systemctl poweroff" to show a extreme
example or take away CAP_SETUID from httpd leading in running as root



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

[Samuli Suominen]

On 01/08/14 18:31, Simon McVittie wrote:
> On 01/08/14 15:53, Simon McVittie wrote:
>> Best-practice in Autotools projects seems to be to include config.h at
>> the very top of every .c file, whether it is currently needed or not.
> Sorry, I'd missed that systemd uses "cc -include
> $(top_builddir)/config.h ...", which is even better. My issues with
> btrfs_ioctl_vol_args must have been caused by something else.
>
> S
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

nod. I've just tested the original patch I posted, seems to work here...
I suppose it's best to apply the initlal patch first, and see if someone
gets a failed build...


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

[Simon McVittie]

On 01/08/14 15:53, Simon McVittie wrote:
> Best-practice in Autotools projects seems to be to include config.h at
> the very top of every .c file, whether it is currently needed or not.

Sorry, I'd missed that systemd uses "cc -include
$(top_builddir)/config.h ...", which is even better. My issues with
btrfs_ioctl_vol_args must have been caused by something else.

S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

[Samuli Suominen]

On 01/08/14 17:53, Simon McVittie wrote:
> On 01/08/14 15:43, Samuli Suominen wrote:
>> Please, #include "missing.h" in src/shared/util.h to fix the build for
>> old systems w/ no system header defining
>> the struct
> I ran into the same thing on a slightly odd system (Debian 7 with a
> backported kernel, so it has Linux 3.14 but only glibc 2.13)

Almost same. Same enough to be the same.

> and
> initially tried an identical patch, but it turned out to break the
> build, because missing.h redefines a bunch of stuff from 

Ah, should have verified with a full build. Nice catch!

> Thanks for reminding me to upstream this!

Likewise.

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

[Simon McVittie]

On 01/08/14 15:43, Samuli Suominen wrote:
> Please, #include "missing.h" in src/shared/util.h to fix the build for
> old systems w/ no system header defining
> the struct

I ran into the same thing on a slightly odd system (Debian 7 with a
backported kernel, so it has Linux 3.14 but only glibc 2.13) and
initially tried an identical patch, but it turned out to break the
build, because missing.h redefines a bunch of stuff from 
if HAVE_LINUX_BTRFS_H is not defined, and if you don't include config.h,
that symbol will never be defined.

The attached patch is what I'm using, and might be closer to correct,
although I think to be fully portable (e.g. to Debian 7 with its
original Linux 3.2) the inclusion of  might need to be
wrapped in #ifdef HAVE_LINUX_BTRFS_H too. I haven't tried that
configuration.

Best-practice in Autotools projects seems to be to include config.h at
the very top of every .c file, whether it is currently needed or not.

Thanks for reminding me to upstream this!

S

>From 669af691816ee56dbf097ae7f0e4f207af5929f5 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 29 Jul 2014 14:40:18 +0100
Subject: [PATCH] util.h: include missing.h, for struct file_handle

This breaks udev-builtin-btrfs.c, which reinvents some of missing.h,
so use missing.h there too.
---
 src/shared/util.h |  1 +
 src/udev/udev-builtin-btrfs.c | 10 --
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/shared/util.h b/src/shared/util.h
index b00395c..e40687e 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -43,6 +43,7 @@
 #include 
 
 #include "macro.h"
+#include "missing.h"
 #include "time-util.h"
 
 union dirent_storage {
diff --git a/src/udev/udev-builtin-btrfs.c b/src/udev/udev-builtin-btrfs.c
index f7bea69..5e1e262 100644
--- a/src/udev/udev-builtin-btrfs.c
+++ b/src/udev/udev-builtin-btrfs.c
@@ -17,6 +17,8 @@
   along with systemd; If not, see .
 ***/
 
+#include "config.h"
+
 #include 
 #include 
 #include 
@@ -24,15 +26,11 @@
 #include 
 #include 
 #include 
+#include 
 
+#include "missing.h"
 #include "udev.h"
 
-#define BTRFS_PATH_NAME_MAX 4087
-struct btrfs_ioctl_vol_args {
-int64_t fd;
-char name[BTRFS_PATH_NAME_MAX + 1];
-};
-#define BTRFS_IOCTL_MAGIC 0x94
 #define BTRFS_IOC_DEVICES_READY _IOR(BTRFS_IOCTL_MAGIC, 39, struct btrfs_ioctl_vol_args)
 
 static int builtin_btrfs(struct udev_device *dev, int argc, char *argv[], bool test)
-- 
2.0.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

[Samuli Suominen]

Mike Frysinger pointed out util.h is using a struct defined in missing.h
but doesn't #include it:

util.h has:

union file_handle_union {
struct file_handle handle;
char padding[sizeof(struct file_handle) + MAX_HANDLE_SZ];
};

missing.h has:

#if !HAVE_DECL_NAME_TO_HANDLE_AT
struct file_handle {
unsigned int handle_bytes;
int handle_type;
unsigned char f_handle[0];
};

static inline int name_to_handle_at(int fd, const char *name, struct
file_handle *handle, int *mnt_id, int flags) {
return syscall(__NR_name_to_handle_at, fd, name, handle, mnt_id,
flags);
}
#endif

Please, #include "missing.h" in src/shared/util.h to fix the build for
old systems w/ no system header defining
the struct

Thanks!

- Samuli
>From 4e44677efbcc586716fe65ed044836877315b3f0 Mon Sep 17 00:00:00 2001
From: Samuli Suominen 
Date: Fri, 1 Aug 2014 17:38:38 +0300
Subject: [PATCH] Include missing.h in util.h for missing struct file_handle
 definition

---
 src/shared/util.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/shared/util.h b/src/shared/util.h
index 4529480..bfbcbcd 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -84,6 +84,7 @@
 #endif
 
 #include "macro.h"
+#include "missing.h"
 #include "time-util.h"
 
 /* What is interpreted as whitespace? */
-- 
2.0.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 06/11] There is no ANSI support on common 3215 consoles

[Lennart Poettering]

On Fri, 01.08.14 16:07, Dr. Werner Fink (wer...@suse.de) wrote:

> On Fri, Jun 20, 2014 at 07:03:47PM +0200, Lennart Poettering wrote:
> > 
> > Also, we are not going to add code for any specific weird terminal
> > settings. We will do three levels: TERM=linux for the full Linux
> > console, TERM=vt102 otherwise, and TERM=dumb for the crap that can't do
> > TERM=vt102. But we are not going to hardcode support for any other
> > hardware into this. This is 2014. If IBM still can't build ANSI support in
> > their terminals, then that's the own fault, and they will not get any
> > support beyond TERM=dumb and no color. We will not work-around IBM's
> > choices in systemd's source tree.
> > 
> > Sorry.
> 
> Maybe I'm wrong but this looks like you have no idea how S390x works.
> The terminal emulation is done by the linux kernel which uses the
> capabilities of the two block oriented terminal interfaces of the
> firmware of a s390 (https://en.wikipedia.org/wiki/IBM_3270). One of
> the block oriented terminals are able to do coloring (3270) and the
> other (3215) is not.  Writing Escape Sequences (including carriage return)
> will cause very strange effects with the later block oriented terminal
> (3215) and this is the default interface if you to not use
> 
>conmode=3270
> 
> to switch to 3270 mode.  With 3270 the kernel then maps Escape Sequences
> with the help of linux/drivers/s390/char/tty3270.c onto the real firmware
> interface for the chosen block oriented terminal.
> 
> I do not think that IBM will ``fix'' their s390 firmware due systemd.
> Beside this, what happens if the main system console is a printer
> and not a virtual device.  Or what does happen if it is a serial
> console which can not handle Escape Sequences or can not handle all
> Escape Sequences or use other Escape Sequences as a common VT102?

That's all good and fine. But we are not going to add explicit support
for this exotic stuff in systemd.

For cases like this we should support TERM=dumb. People won't get color
during boot, but things will still work great otherwise.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 06/11] There is no ANSI support on common 3215 consoles

[Dr. Werner Fink]

On Fri, Jun 20, 2014 at 07:03:47PM +0200, Lennart Poettering wrote:
> 
> Also, we are not going to add code for any specific weird terminal
> settings. We will do three levels: TERM=linux for the full Linux
> console, TERM=vt102 otherwise, and TERM=dumb for the crap that can't do
> TERM=vt102. But we are not going to hardcode support for any other
> hardware into this. This is 2014. If IBM still can't build ANSI support in
> their terminals, then that's the own fault, and they will not get any
> support beyond TERM=dumb and no color. We will not work-around IBM's
> choices in systemd's source tree.
> 
> Sorry.

Maybe I'm wrong but this looks like you have no idea how S390x works.
The terminal emulation is done by the linux kernel which uses the
capabilities of the two block oriented terminal interfaces of the
firmware of a s390 (https://en.wikipedia.org/wiki/IBM_3270). One of
the block oriented terminals are able to do coloring (3270) and the
other (3215) is not.  Writing Escape Sequences (including carriage return)
will cause very strange effects with the later block oriented terminal
(3215) and this is the default interface if you to not use

   conmode=3270

to switch to 3270 mode.  With 3270 the kernel then maps Escape Sequences
with the help of linux/drivers/s390/char/tty3270.c onto the real firmware
interface for the chosen block oriented terminal.

I do not think that IBM will ``fix'' their s390 firmware due systemd.
Beside this, what happens if the main system console is a printer
and not a virtual device.  Or what does happen if it is a serial
console which can not handle Escape Sequences or can not handle all
Escape Sequences or use other Escape Sequences as a common VT102?

Werner

-- 
  "Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool." -- Edward Burr


pgpBpq14w6OeI.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/5] kdbus: allow multiple policies

[Djalal Harouni]

Hi,

On Thu, Jul 31, 2014 at 10:38:47PM +0200, Kay Sievers wrote:
> On Thu, Jul 31, 2014 at 8:57 PM, Djalal Harouni  wrote:
> > (Cc'ed Lennart)
> >
> > On Thu, Jul 31, 2014 at 05:40:53PM +0200, Kay Sievers wrote:
> >> On Wed, Jul 23, 2014 at 6:34 PM, Djalal Harouni  wrote:
> >> > This series adds the infrastructure to test and upload multiple
> >> > policies.
> >> >
> >> > The last #5 patch allows to upload multiple policies per connection
> >>
> >> What is the reason for this? A policy holding connection (which
> >> matches a busname unit) shouldn't only be in charge of one single
> >> name?
> > Hmm, I thought that what you describe is for activators?
> 
> Yes, activators can only ever have one name, but policy holders should too.
Ok.

> > I was following the current kdbus spec/code here!
> >
> > From kdbus.h source:
> > "@KDBUS_HELLO_POLICY_HOLDER: Special-purpose connection which registers
> > policy entries for one or multiple names. The provided names are not
> > activated, and are not registered with the name database"
> 
> I'm going to fix that, it does not sound correct.
> 
> We have one .busname file per name and it will get really complicated
> to start stop a busname, when it has multiple names per connection. We
> should really avoid that and require one connection per name and allow
> only name.
I do agree.

> > And the logic in policy.c is set that multiple policy entries can have
> > the same owner which is the policy holding connection:
> >
> > struct kdbus_policy_db_entry {
> > char *name;
> > struct hlist_node hentry;
> > struct list_head access_list;
> > const void *owner;
> > bool wildcard:1;
> >  };
> 
> Only custom endpoints will carry list of policies for different names.
> It looks and acts a little bit like a firewall.
I see the point now!

> > This should allow one single connection to handle multiple policy
> > entries, I think the design is good, since policy entries are then
> > handled internally by kdbus, so only one single connection resources
> > to achieve this, which can be reliable on private domains,buses...
> 
> Resources don't really matter here, they are cheap. We need to keep
> things simple and robust, and managing lists of names in userspace
> when the configuration changes would get really complicated.
Yes, I was also worried about configuration changes. Well you are right
here. I did like the fact that on a private bus, a connection might hold
multiple policies for multiple names, but yes there will be problems
when updating/deleting multiple policies...


> > The policy holding connection acts like create policy entries, and
> > invalidate them when it is closed!
> 
> Yes, all that should already work with systemd.
> 
> > Still I see three points here from how much pressure and job should
> > the policy holding connection do!
> > 1) Register policy entries (handled internally), no communication
> > 2) Register policy entries + do basic communication based on ID
> > 3) Register policy entries + acquire name or names + do communication
> >based on names...
> 
> Policy holders and activators can never communicate. Activator
> connection can get messages queued, but they cannot be received by the
> activator connection.
Ok, I will give it a review and send patches for kdbus and the
test-kdbus-policy tests, since now in test-kdbus-policy a policy holder
is able to receive messages.

So I'll updated based on these comments, thanks!

> > All of these points are from the perspective: if the policy holding
> > connection dies, all the registered policy entries will go away, thus
> > invalidating all communications to the registered names...
> >
> > Should we care ?
> 
> It should all work that way already.
Yes, but I'll give it a review and write tests for these cases.


> > And for that patch change, it will block activators from having
> > multiple names, it will fail, but it will succeed for policy holders.
> 
> Which is intentional. Sorry for the misleading text in the docs.
Hopefully it got catched now :-)


> >> > The todo for the policy holders is:
> >> >
> >> > * Should we set a maximum value for how many names/policies a policy
> >> >  holder is allowed to upload. This is needed since we do not want to
> >> >  consume all the entries (kdbus_policy_db->entries_hash).
> >>
> >> Yes, everything that consumes kernel memory needs to be limited.
> > Ok, so this needs a proper discussion, will send about it and Cc Lennart
> > too.
> 
> We need to limit the size of the uploaded policy, just like we limit
> the amount of messages.
> 
> > So perhaps do not apply this series until we have a proper limit.
> >
> >> > * Update/test the kdbus_policy_set() to work with multiple names.
> >>
> >> This is meant for custom endpoints, not for policy-holder connections?
> > Currently it is aimed to work for both of them!
> >
> > I've tested for policy-holder connections and it works with this series
> > applied, but only when we create new

Re: [systemd-devel] [PATCH 0/5] kdbus: allow multiple policies

[Simon McVittie]

On 01/08/14 12:20, Kay Sievers wrote:
> On Fri, Aug 1, 2014 at 1:13 PM, Simon McVittie
>  wrote:
>> are you saying that under kdbus, each connection to the bus [...] is only
>> allowed to own one well-known name (thing like org.freedesktop.systemd1)?
> 
> No, it is not about connections that exchange messages, but about
> policy holders which cannot communicate themselves.
> 
> Ordinary connections can own many well-known names.

Thanks for clarifying. That's the answer I was hoping for.

S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/5] kdbus: allow multiple policies

[Kay Sievers]

On Fri, Aug 1, 2014 at 1:13 PM, Simon McVittie
 wrote:
> On 31/07/14 21:38, Kay Sievers wrote:
>> We have one .busname file per name and it will get really complicated
>> to start stop a busname, when it has multiple names per connection. We
>> should really avoid that and require one connection per name and allow
>> only name.
>
> I might be misunderstanding what you're getting at here (unfortunately I
> still haven't had time to review the kdbus design or codebase in detail)
> but are you saying that under kdbus, each connection to the bus (thing
> with a unique name like :1.42, analogous to DBusConnection) is only
> allowed to own one well-known name (thing like org.freedesktop.systemd1)?

No, it is not about connections that exchange messages, but about
policy holders which cannot communicate themselves.

Ordinary connections can own many well-known names.

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/5] kdbus: allow multiple policies

[Simon McVittie]

On 31/07/14 21:38, Kay Sievers wrote:
> We have one .busname file per name and it will get really complicated
> to start stop a busname, when it has multiple names per connection. We
> should really avoid that and require one connection per name and allow
> only name.

I might be misunderstanding what you're getting at here (unfortunately I
still haven't had time to review the kdbus design or codebase in detail)
but are you saying that under kdbus, each connection to the bus (thing
with a unique name like :1.42, analogous to DBusConnection) is only
allowed to own one well-known name (thing like org.freedesktop.systemd1)?

If that's true, then I need to raise a red flag here: that would be a
significant regression compared with traditional D-Bus, and is going to
break the semantics of currently-working applications if an existing
library like GDBus or libdbus moves from traditional D-Bus to kdbus. We
have always advised applications to try to avoid having more than one
connection to the same bus, because messages received from different
buses arrive in an undefined order, breaking total or even causal
ordering (and I've seen this cause real-world bugs). So if an
application needs more than one name, for which there are many
real-world uses, it would currently use one connection to the bus to own
all those names, preserving total ordering of messages to all of those
names.

I hope I'm just misunderstanding your message, though.

S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel