[systemd-devel] [PATCH] networkd: Support VXlan parameters
Add vxlan paramertes to config.
---
man/systemd.netdev.xml | 30 +
src/network/networkd-netdev-gperf.gperf | 7 ++-
src/network/networkd-netdev-vxlan.c | 75 +
src/network/networkd-netdev-vxlan.h | 8
src/network/networkd.h | 11 +
5 files changed, 130 insertions(+), 1 deletion(-)
diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
index 275ee52..e25c1c4 100644
--- a/man/systemd.netdev.xml
+++ b/man/systemd.netdev.xml
@@ -272,6 +272,36 @@
to discover remote MAC
addresses.
+
+
FDBAgeingSec=
+
+The lifetime of FDB
entries learnt by the kernel in seconds.
+
+
+
+
ARPProxy=
+
+A boolean. When true,
enables ARP proxy.
+
+
+
+L2Miss=
+
+A boolean. When true,
enables netlink LLADDR miss notifications.
+
+
+
+L3Miss=
+
+A boolean. When true,
enables netlink IP ADDR miss notifications.
+
+
+
+
RouteSC=
+
+A boolean. When true
route short circuit is turned on.
+
+
diff --git a/src/network/networkd-netdev-gperf.gperf
b/src/network/networkd-netdev-gperf.gperf
index c524ee5..5ee5380 100644
--- a/src/network/networkd-netdev-gperf.gperf
+++ b/src/network/networkd-netdev-gperf.gperf
@@ -37,10 +37,15 @@ Tunnel.DiscoverPathMTU, config_parse_bool,
0,
Peer.Name, config_parse_ifname,0,
offsetof(Veth, ifname_peer)
Peer.MACAddress, config_parse_hwaddr,0,
offsetof(Veth, mac_peer)
VXLAN.Id,config_parse_uint64,0,
offsetof(VxLan, id)
-VXLAN.Group, config_parse_tunnel_address,0,
offsetof(VxLan, group)
+VXLAN.Group, config_parse_vxlan_group_address, 0,
offsetof(VxLan, group)
VXLAN.TOS, config_parse_unsigned, 0,
offsetof(VxLan, tos)
VXLAN.TTL, config_parse_unsigned, 0,
offsetof(VxLan, ttl)
VXLAN.MacLearning, config_parse_bool, 0,
offsetof(VxLan, learning)
+VXLAN.ARPProxy, config_parse_bool, 0,
offsetof(VxLan, arp_proxy)
+VXLAN.L2Miss,config_parse_bool, 0,
offsetof(VxLan, l2miss)
+VXLAN.L3Miss,config_parse_bool, 0,
offsetof(VxLan, l3miss)
+VXLAN.RouteSC, config_parse_bool, 0,
offsetof(VxLan, route_short_circuit)
+VXLAN.FDBAgeingSec, config_parse_sec, 0,
offsetof(VxLan, fdb_ageing)
Tun.OneQueue,config_parse_bool, 0,
offsetof(TunTap, one_queue)
Tun.MultiQueue, config_parse_bool, 0,
offsetof(TunTap, multi_queue)
Tun.PacketInfo, config_parse_bool, 0,
offsetof(TunTap, packet_info)
diff --git a/src/network/networkd-netdev-vxlan.c
b/src/network/networkd-netdev-vxlan.c
index 326ac54..076e266 100644
--- a/src/network/networkd-netdev-vxlan.c
+++ b/src/network/networkd-netdev-vxlan.c
@@ -26,6 +26,7 @@
#include "sd-rtnl.h"
#include "networkd-netdev-vxlan.h"
#include "networkd-link.h"
+#include "conf-parser.h"
#include "missing.h"
static int netdev_vxlan_fill_message_create(NetDev *netdev, Link *link,
sd_rtnl_message *m) {
@@ -92,9 +93,
[systemd-devel] Automatic journal check?
Hello, My journal gets corrupted on pretty much a daily basis. I typically notice this because things like "systemctl -n 3" take ages to run. When I then run "journalctl --verify", I get output like this: Invalid data object at hash entry 3944 of 233016░░░ 49% File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/user-1000@0005065350521a47-17e420d2d51ab126.journal~:00 (of 8388608 bytes, 0%). Data object references invalid entry at 5182040███░ 75% File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/system@00050713408c0d34-e40e6aa5c35eb139.journal~:00 (of 8388608 bytes, 0%). FAIL: /var/log/journal/b865c77cc176b5ef3b69390a000d/system@00050713408c0d34-e40e6aa5c35eb139.journal~ (Bad message) Data number mismatch██░ 39% File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/system@000507165d32850c-5b4cd09ceb6b2ea6.journal~:00 (of 16777216 bytes, 0%). Invalid tail monotonic timestamp░░░ 48% File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/user-65534@763da377eefc4369ad61af34c4a5a1c6-000263f0-000504a444037da7.journal:00 (of 8388608 bytes, 0%). This corruption is probably caused by me hard-rebooting the computer recently to debug some other issues. However, I think it's quite unfortunate that journald isn't able to recover from this on its own. Is there a reason why the journal doesn't have a "clean" flag like regular file systems? This would allow an automatic --verify run when the journal has not been closed properly, and would save people like me the trouble of monitoring this manually. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown problems
On 11/13/2014 12:54 PM, Nikolaus Rath wrote: > Nikolaus Rath writes: >> Lennart Poettering writes: >>> On Sat, 08.11.14 11:16, Nikolaus Rath (nikol...@rath.org) wrote: >>> > Please boot with "systemd.log_level=debug", then make the machine hang > and check what the last things in the logs say. Maybe then paste that > somewhere online and post the URL for that here, so that we can have a > look. Here's the output (obtained by changing log level and remounting earlier in the debug.sh script): https://dl.dropboxusercontent.com/u/11545826/shutdown.log Thanks for your help! >>> >>> Hmm the logs show that systemd pretty much completed its >>> shutdown. After the message "Cannot finalize remaining DM devices, >>> continuing." the only thing that still runs is the shutdown hooks you >>> used to generate this log, plus either a jump back into your initrd >>> (if your initrd supports that) or the reboot() system call. >>> >>> If the latter hangs then it's a kernel bug. >> >> reboot -f works fine - could it still be a kernel bug? >> >>> Please check if there are any other scripts in >>> /lib/systemd/system-shutdown/ that might be at fault here. >> >> Nope, none. >> >>> Please check if your initrd is one of those which support jumping back >>> into the initrd on shutdown. For that check if /run/initramfs/shutdown >>> exists during runtime and is executable. >> >> No, /run/initramfs/shutdown does not exist. >> >>> If so, it's probably an >>> initrd problem, please file a bug against your initrd implementation. >>> >>> You appear to be using LVM, I wouldn't be surprised if LVM is broken >>> here, but I cannot help you debugging this, please contact the LVM >>> maintainers in this case. >> >> Is there some indication that LVN is at fault? As I said in my first >> email, the crucial difference seems to be if an X11 console is active or >> not: >> >> * If I execute "systemctl reboot" while a text console is active, >>everything works fine. >> >> * If I execute "systemctl reboot" while the X11 console is active, the >>system hangs (I tried waiting up to 7 minutes). Furthermore, I am >>unable to switch to another console with Ctrl+Alt+Fn, the computer >>becomes unresponsive to the keyboard and the monitor powers down. >> >> On which tty/pty systemctl itself is executed does not matter (I tested >> this by running systemctl in an ssh session from a remote system), it >> only matters which console is currently active. > > Some more information: > > * if I start a debug-shell on a serial port, at some point the shell > seems to freeze as well. > > * if I boot with sysvinit instead of systemd things work fine: > > - The system reboots even if an X11 console is active > - During the shutdown, I can switch between text consoles and see > log messages > > Any ideas? On a whim, I also tried blacklisting the nouveau module and using the integrated graphics with the i915 module instead. It did not make a difference. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown problems
Nikolaus Rath writes: > Lennart Poettering writes: >> On Sat, 08.11.14 11:16, Nikolaus Rath (nikol...@rath.org) wrote: >> >>> > Please boot with "systemd.log_level=debug", then make the machine hang >>> > and check what the last things in the logs say. Maybe then paste that >>> > somewhere online and post the URL for that here, so that we can have a >>> > look. >>> >>> Here's the output (obtained by changing log level and remounting earlier >>> in the debug.sh script): >>> >>> https://dl.dropboxusercontent.com/u/11545826/shutdown.log >>> >>> Thanks for your help! >> >> Hmm the logs show that systemd pretty much completed its >> shutdown. After the message "Cannot finalize remaining DM devices, >> continuing." the only thing that still runs is the shutdown hooks you >> used to generate this log, plus either a jump back into your initrd >> (if your initrd supports that) or the reboot() system call. >> >> If the latter hangs then it's a kernel bug. > > reboot -f works fine - could it still be a kernel bug? > >> Please check if there are any other scripts in >> /lib/systemd/system-shutdown/ that might be at fault here. > > Nope, none. > >> Please check if your initrd is one of those which support jumping back >> into the initrd on shutdown. For that check if /run/initramfs/shutdown >> exists during runtime and is executable. > > No, /run/initramfs/shutdown does not exist. > >> If so, it's probably an >> initrd problem, please file a bug against your initrd implementation. >> >> You appear to be using LVM, I wouldn't be surprised if LVM is broken >> here, but I cannot help you debugging this, please contact the LVM >> maintainers in this case. > > Is there some indication that LVN is at fault? As I said in my first > email, the crucial difference seems to be if an X11 console is active or > not: > > * If I execute "systemctl reboot" while a text console is active, >everything works fine. > > * If I execute "systemctl reboot" while the X11 console is active, the >system hangs (I tried waiting up to 7 minutes). Furthermore, I am >unable to switch to another console with Ctrl+Alt+Fn, the computer >becomes unresponsive to the keyboard and the monitor powers down. > > On which tty/pty systemctl itself is executed does not matter (I tested > this by running systemctl in an ssh session from a remote system), it > only matters which console is currently active. Some more information: * if I start a debug-shell on a serial port, at some point the shell seems to freeze as well. * if I boot with sysvinit instead of systemd things work fine: - The system reboots even if an X11 console is active - During the shutdown, I can switch between text consoles and see log messages Any ideas? Thanks, Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'systemctl poweroff' no longer shuts down system -- instead, reboots ?
On Tue, Nov 11, 2014, at 08:09 AM, Lennart Poettering wrote: > On the upstream ML we usually discuss only more recent problems, which > are exposed upstream. Hence, please contact the Suse folks for more > help on the issue, or check if a current systemd version fails. Already done, and just fyi -- appears now to be fixed: @ https://bugzilla.suse.com/show_bug.cgi?id=903560#c48 rpm -q --changelog systemd * Thu Nov 13 2014 wer...@suse.de - Change patch 0001-add-hdflush-for-reboot-or-hddown-for-poweroff.patch to skip hdflush as well as hddown but only use halt as fallback for poweroff as well as synch in systemctl before any reboot command (compare with commit 4a3ad39957399c4a30fc472a804e72907ecaa4f9) https://build.opensuse.org/package/view_file/Base:System/systemd/0001-add-hdflush-for-reboot-or-hddown-for-poweroff.patch?expand=1 shutdown now shuts down correctly. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] xinetd REMOTE_IP (feature request)
On Thu, Nov 13, 2014 at 8:58 PM, Tomasz Torcz wrote:
> On Thu, Nov 13, 2014 at 01:53:12PM -0500, Fisher, Charles J. (Top Echelon)
> wrote:
> > The xinetd server from previous versions of RedHat defined a REMOTE_IP
> environment variable.
> >
> > I realize that I can extract that data with the following code:
> >
> > {
> > struct sockaddr_in thisconn;
> > int thislen = sizeof(thisconn);
> > getpeername( /* STDIN */ 0, &thisconn, &thislen);
> > printf("%s\n", inet_ntoa(thisconn.sin_addr));
> > }
> >
> > ...but it would be nice if the behavior matched xinetd.
>
> You can do it in shell by parsing instance name embedded
> in /proc/self/cgroup
>
I'm not sure whether the instance names are something that should be relied
on?
(Not to mention that it'll probably take twice as much code as
getpeername().)
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] xinetd REMOTE_IP (feature request)
On Thu, Nov 13, 2014 at 01:53:12PM -0500, Fisher, Charles J. (Top Echelon)
wrote:
> The xinetd server from previous versions of RedHat defined a REMOTE_IP
> environment variable.
>
> I realize that I can extract that data with the following code:
>
> {
> struct sockaddr_in thisconn;
> int thislen = sizeof(thisconn);
> getpeername( /* STDIN */ 0, &thisconn, &thislen);
> printf("%s\n", inet_ntoa(thisconn.sin_addr));
> }
>
> ...but it would be nice if the behavior matched xinetd.
You can do it in shell by parsing instance name embedded
in /proc/self/cgroup
--
Tomasz Torcz RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] xinetd REMOTE_IP (feature request)
The xinetd server from previous versions of RedHat defined a REMOTE_IP
environment variable.
I realize that I can extract that data with the following code:
{
struct sockaddr_in thisconn;
int thislen = sizeof(thisconn);
getpeername( /* STDIN */ 0, &thisconn, &thislen);
printf("%s\n", inet_ntoa(thisconn.sin_addr));
}
...but it would be nice if the behavior matched xinetd.
The environment that I see defined by systemd is:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
PWD=/
LANG=en_US.utf8
SHLVL=1
_=/usr/bin/env
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus-proxy: cloning smack label
When dbus client connects to systemd-bus-proxyd through
Unix domain socket proxy takes client's smack label and sets for itself.
It is done before and independent of dropping privileges.
The reason of such soluton is fact that tests of access rights
performed by lsm may take place inside kernel, not only
in userspace of recipient of message.
The bus-proxyd needs CAP_MAC_ADMIN to manipulate its label.
In case of systemd running in system mode, CAP_MAC_ADMIN
should be added to CapabilityBoundingSet in service file of bus-proxyd.
In case of systemd running in user mode ('systemd --user')
it can be achieved by addition
Capabilities=cap_mac_admin=i and SecureBits=keep-caps
to user@.service file
and setting cap_mac_admin+ei on bus-proxyd binary.
Change-Id: I0acb5ec0d9ce4aecf25ddb0ca0e137b7a187a02f
---
Makefile.am | 4 ++--
src/bus-proxyd/bus-proxyd.c | 17 +
src/shared/capability.c | 18 ++
src/shared/capability.h | 2 ++
units/systemd-bus-pro...@.service.in| 22 --
units/systemd-bus-pro...@.service.m4.in | 22 ++
units/u...@.service.in | 19 ---
units/u...@.service.m4.in | 23 +++
8 files changed, 84 insertions(+), 43 deletions(-)
delete mode 100644 units/systemd-bus-pro...@.service.in
create mode 100644 units/systemd-bus-pro...@.service.m4.in
delete mode 100644 units/u...@.service.in
create mode 100644 units/u...@.service.m4.in
diff --git a/Makefile.am b/Makefile.am
index 701666c..e9db1f3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -588,7 +588,7 @@ EXTRA_DIST += \
units/user/systemd-exit.service.in \
units/systemd-f...@.service.in \
units/systemd-fsck-root.service.in \
- units/u...@.service.in \
+ units/u...@.service.m4.in \
units/debug-shell.service.in \
units/systemd-suspend.service.in \
units/quotaon.service.in \
@@ -2528,7 +2528,7 @@ dist_userunit_DATA += \
endif
EXTRA_DIST += \
- units/systemd-bus-pro...@.service.in \
+ units/systemd-bus-pro...@.service.m4.in \
units/user/systemd-bus-pro...@.service.in
#
--
diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index d6607ed..08e2c7c 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -45,6 +45,7 @@
#include "def.h"
#include "capability.h"
#include "bus-policy.h"
+#include "smack-util.h"
static char *arg_address = NULL;
static char *arg_command_line_buffer = NULL;
@@ -1234,6 +1235,22 @@ int main(int argc, char *argv[]) {
if (is_unix) {
(void) getpeercred(in_fd, &ucred);
(void) getpeersec(in_fd, &peersec);
+
+#ifdef HAVE_SMACK
+if (mac_smack_use()) {
+if (peersec) {
+
+r = mac_smack_apply_pid(getpid(), peersec);
+if (r < 0)
+log_warning("Failed to set SMACK label
%s : %s", peersec, strerror(-r));
+} else
+log_warning("Invalid SMACK label");
+
+r = drop_capability(CAP_MAC_ADMIN);
+if (r < 0)
+log_warning("Failed to drop CAP_MAC_ADMIN:
%s", strerror(-r));
+}
+#endif
}
if (arg_drop_privileges) {
diff --git a/src/shared/capability.c b/src/shared/capability.c
index 0226542..9dc42ec 100644
--- a/src/shared/capability.c
+++ b/src/shared/capability.c
@@ -285,3 +285,21 @@ int drop_privileges(uid_t uid, gid_t gid, uint64_t
keep_capabilities) {
return 0;
}
+
+int drop_capability(cap_value_t cv) {
+_cleanup_cap_free_ cap_t tmp_cap = NULL;
+
+tmp_cap = cap_get_proc();
+if (!tmp_cap)
+return -errno;
+
+if ((cap_set_flag(tmp_cap, CAP_INHERITABLE, 1, &cv, CAP_CLEAR) < 0) ||
+(cap_set_flag(tmp_cap, CAP_PERMITTED, 1, &cv, CAP_CLEAR) < 0) ||
+(cap_set_flag(tmp_cap, CAP_EFFECTIVE, 1, &cv, CAP_CLEAR) < 0))
+return -errno;
+
+if (cap_set_proc(tmp_cap) < 0)
+return -errno;
+
+return 0;
+}
diff --git a/src/shared/capability.h b/src/shared/capability.h
index 3e6d999..6f2f6f9 100644
--- a/src/shared/capability.h
+++ b/src/shared/capability.h
@@ -34,6 +34,8 @@ int capability_bounding_set_drop_usermode(uint64_t drop);
int drop_privileges(uid_t uid, gid_t gid, uint64_t keep_capabilites);
+int drop_capability(cap_value_t cv);
+
DEFINE_TRIVIAL_CLEANUP_FUNC(cap_t, cap_free);
#define _cleanup_cap_free_ _cleanup_(cap_freep)
diff --git a/units/systemd-bus-pro...@.service.in
b/units/systemd-bus-pro...@.service.in
deleted file mode 100644
index eef703f..000
-
[systemd-devel] [PATCH v8] tmpfiles, man: Add xattr support to tmpfiles
This patch makes it possible to set extended attributes on files created
by tmpfiles. This can be especially used to set SMACK security labels on
volatile files and directories.
It is done by adding new line of type "t". Such line should contain
attributes in Argument field, using following format:
name=value
All other fields are ignored.
If value contains spaces, then it must be surrounded by quotation marks.
User can also put quotation mark in value by escaping it with backslash.
Example:
D /var/run/cups - - - -
t /var/run/cups - - - - security.SMACK64=printing
---
v8:
* update man
v7:
* use strv_consume() instead of strv_extend()
* use only lsetxattr()
* do not label in 'z' option
* style fixes and cleanup
v6:
* rebase
* man fixes
* use glibc xattr
* use unquote_first_word() instead of own parsing logic
v5:
* fixes for HAVE_XATTR undefined
* use cunescape() instead of strreplace()
* cache result of strv_length()
* fix typo in manpage
v4:
* grammar fix in man
* style fix
v3:
* "may be used" instead of "should be used" in manpage
* use strv_isempty() instead of != NULL
* rework item_set_xattrs() with split_pair()
* remove copy_item_contents()
* use hashmap_replace() instead of removed copy_item_contents()
* use strv_extend() instead of strv_append()
* cleanup
---
man/tmpfiles.d.xml | 32 +--
src/tmpfiles/tmpfiles.c | 145
2 files changed, 159 insertions(+), 18 deletions(-)
diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index 1b14d69..4f2e640 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -343,6 +343,25 @@ L/tmp/foobar ----
/dev/null
normal path
names.
+
+
+t
+Set extended
+attributes on item. It may be
+used in conjunction with other
+types (only d,
+D,
f,
+F,
L,
+p,
c,
+b, makes sense).
+If used as a standalone line, then
+systemd-tmpfiles
+will try to set extended
+attributes on specified path.
+This can be especially used to set
+SMACK labels.
+
+
If the exclamation mark is used, this
@@ -430,7 +449,7 @@ r! /tmp/.X[0-9]*-lock
will not be modified. This parameter is
ignored for x,
r, R,
-L lines.
+L, t
lines.
Optionally, if prefixed with
~, the access mode is masked
@@ -462,8 +481,8 @@ r! /tmp/.X[0-9]*-lock
ownership will not be modified. These
parameters are ignored for
x, r,
-R, L
-lines.
+R, L,
+t lines.
@@ -527,8 +546,8 @@ r! /tmp/.X[0-9]*-lock
specify a short string that is written to the
file, suffixed by a newline. For
C, specifies the source file
-or directory. Ignored for all other
-lines.
+or directory. For t determines
+extended attributes to be set. Ignored for all other
lines.
@@ -540,7 +559,8 @@ r! /tmp/.X[0-9]*-lock
screen needs two directories
created at boot with specific modes and ownership.
d /run/screens 1777 root root 10d
-d /run/uscreens 0755 root root 10d12h
+d /run/uscreens 0755 root root 10d12h
+t /run/screen - - - - user.name="John Smith"
security.SMACK64=screen
/etc/tmpfiles.d/abrt.conf example
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 1e4675f..c5bb4e7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "log.h"
#include "util.h"
@@ -71,6 +72,7 @@ typedef enum ItemType {
CREATE_CHAR_DEVICE = 'c',
CREATE_BLOCK_DEVICE = 'b',
COPY_FILES = 'C',
+SET_XATTR = 't',
Re: [systemd-devel] [PATCH 2/2] keymap: Fix special keys on ThinkPad X60/X61 Tablet
Hello again, Martin Pitt [2014-11-13 9:00 +0100]: > I haven't seen such a laptop myself yet, but the best photo I could > find on the interweb is > http://images.harlander.com/upload/files/artikelbilder/computer/notebooks/lenovo/x60/mit_dock/1000x1000.jpg > > There are three round black push buttons at the bottom screen edge; > the first one is obviously the rotation from above, the third is > Escape, the second one is indecipherable for me. Ah, nevermind. When searching for an X41 for your other patch, I found http://www.ecoshop.biz/pics/3005/gallery/ThinkPad_X41_Tablet_2.jpg which is quite sharp and clear to recognize. This indeed is a toolbox :-) I pushed both patches. Thank you! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] keymap: Fix special keys on ThinkPad X60/X61 Tablet
Hey Bastien, Bastien Nocera [2014-11-12 23:31 +0100]: > KEY_DIRECTION is mapped to XF86RotateWindows, to rotate the display: > http://cgit.freedesktop.org/xkeyboard-config/commit/symbols/inet?id=ec875f6f9b7c4028e11d32b071989c682e6502bd Ack, good to know. F21 is indeed wrong, that's Touchpad Toggle these days. > And F13 is mapped to XF86Tools, which is closest to the original toolbox > usage: > - KEYBOARD_KEY_68=screenlock # screenlock > + KEYBOARD_KEY_68=f13# toolbox I haven't seen such a laptop myself yet, but the best photo I could find on the interweb is http://images.harlander.com/upload/files/artikelbilder/computer/notebooks/lenovo/x60/mit_dock/1000x1000.jpg There are three round black push buttons at the bottom screen edge; the first one is obviously the rotation from above, the third is Escape, the second one is indecipherable for me. It neither looks like a "screen lock" nor a "tool box" to me, though; is that the button which generates code 68 which this part of the patch addresses? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
