Re: [systemd-devel] How to add a second bridge to a nspawn container?
El 04-01-2019 a las 2:50, Mantas Mikulėnas escribió: That's because the specified interface is not a bridge... Yeah, that and it is a wireless interface..it may not work .. OP needs to use ipvlan instead. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clang-format: auto-formatting the code base of systemd
Hello Giacinto, from a semantic point of view the source code should not change at all with clang-format. There is only one problem with the custom preprocessor pragma for the "new" keyword, which needs to be excluded explicitly. See old pull request here: https://github.com/systemd/systemd/pull/11254 Despite of that the whole source code can be reformatted. I tried compiling after reformatting, which ran all tests just fine. But the formatting output has to be checked, as some code might better be reformatted by hand to enhance readability. But this is 'just' about source code style. Still a test of binary equality of the compiled binaries would be nice, to assure that no meaning has been changed. Thanks and Cheers, Sebastian On 04.01.19 14:48, Giacinto Cifelli wrote: Hello Sebastian, - reformats all existing code, which requires review this can be possibly be automated, by comparing the generated precompiled files. Cheers, Sebastian Jennen Regards, Giacinto ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clang-format: auto-formatting the code base of systemd
Hello Sebastian, > - reformats all existing code, which requires review this can be possibly be automated, by comparing the generated precompiled files. > > Cheers, Sebastian Jennen > Regards, Giacinto ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] clang-format: auto-formatting the code base of systemd
Hello systemd team, there is a pull request currently on systemd, which adds a .clang-format support, which you can find here: https://github.com/systemd/systemd/pull/11308 clang-format is an automatic formatter for C code maintained by the llvm project. It works by tokenizing the source code and reassembling it under consideration of a single source code style defining file (.clang-format). I would like to ask you to participate on a poll on this, as this topic is controversial. One the hand this: - enables programmers to auto-format their patches to comply with the systemd style - fixes a couple of minor code inconsistencies on the other hand this: - reformats all existing code, which requires review - break some systemd specific styles which would need be changed some way (see especially the formatting of table blocks in pull request) - may annoy some developers, as custom styling is lost Please also take into consideration the suggested file tools/format-file.py to extend the clang-format formatting. Here are poll alternatives in detail, to the question, whether the new style should be applied: no --> speaks for itself no, --> but *some* features should be derived from it and applied to the code base. That would be tedious and not automatable for future changes. This will not enable programmers to auto apply the code format to their patches, as this format would need to be cherry picked for the reformatting allowed by systemd. yes --> but with the wrapper script in tools/format-file.py as mentioned in the pr to be as close as possible to the existing style Together with this script the coding style already comes quite close to the style in systemd right now. All custom changes in tools/format-file.py have been posted on the llvm mailing list, so these changes might be implemented upstream so the custom script might eventually get redundant with a newer version of clang-format. see request on mailing list here: http://lists.llvm.org/pipermail/cfe-dev/2019-January/060690.html yes --> clang-format should applied in the pure form defined by the .clang-format file without any wrapper script. This makes the most changes to the code base, but also makes it most obvious how to auto-format the code. Independently source code style file and the wrapper script can further be changed. You can find the poll here: http://www.easypolls.net/poll.html?p=5c2f3659e4b026f889160411 Cheers, Sebastian Jennen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a second bridge to a nspawn container?
04.01.2019 6:23, Alexander E. Patrakov пишет: >> >> I am not sure whether "Operation not supported" means that there is >> something wrong with that config? or that it is not possible to create a >> bridge to a wireless NIC? > > To be able to participate in a bridge, the wireless card must act as > an access point. This restriction comes from the fact that, generally, > there are 4 MAC addresses that one needs to be concerned about: Access > Point, Station, Source and Destination, but a wireless packet can > contain only three distinct ones. Being an access point helps, because > one knows that there are no bridges on the far end, i.e. all incoming > packets have Station = Source, and all outgoing packets except > multicast have Station = Destination. > Actually wireless packet has space for 4 MAC addresses, this is how WDS works. Depending on wireless adapter and driver it may be possible to set 4addr mode. But this most likely requires special explicit configuration on AP side to allow WDS from specific MAC. Good overview is here: http://nullroute.eu.org/~grawity/journal-2011.html#post:20110826 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] sd-bus parameter names
Hi,
I would like to give my DBus parameters names other than the default
arg_X for the introspection.
Is it ok if I post some commits to do that, or is the feature excluded
by choice?
The changes I would propose are:
- sd-bus-vtable.h: struct sd_bus_vtable extended like:
struct sd_bus_vtable {
/* Please do not initialize this structure directly, use the
* macros below instead */
uint8_t type:8;
uint64_t flags:56;
union {
struct {
size_t element_size;
} start;
struct {
const char *member;
const char *signature;
const char *in_names;
const char *result;
const char *out_names;
sd_bus_message_handler_t handler;
size_t offset;
} method;
struct {
const char *member;
const char *signature;
const char *out_names;
} signal;
struct {
const char *member;
const char *signature;
sd_bus_property_get_t get;
sd_bus_property_set_t set;
size_t offset;
} property;
} x;
};
The names would be separated by spaces for ease of coding. If the list
is too long, additional parameters are ignores, if too short, no name
tag is given (hence backward compatibility).
- additional macros for adding the name strings.
- processing of this additional information in bus-introspect.c,
changing the introspect_write_arguments:
static int introspect_write_arguments(struct introspect *i,
const char *signature, const char *direction, const char *names)
and related call in introspect_write_interface.
Thank you,
Regards,
Giacinto
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
