As Andries notes, this piece of text is rather out of place in
a page that was intended to provide a tutorial introduction for
beginners logging in on a Linux system.
Reported-by: Andries E. Brouwer <Andries.Brouwer@cwi.nl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The "ABI" doesn't really convey anything significant in
the title. These subsections are about describing differences
between the kernel and (g)libc interfaces.
Reported-by: Andries E. Brouwer <Andries.Brouwer@cwi.nl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A PTY is not like a pipe - there may be delayed between data
being written at one end and it being available at the other.
This became particularly apparent after
commit f95499c3030f
("n_tty: Don't wait for buffer work in read() loop")
in Linux 3.12
See also the mail thread at https://lkml.org/lkml/2015/5/1/35
Date Mon, 04 May 2015 12:32:04 -0400
From Peter Hurley <>
Subject Re: [PATCH bisected regression] input_available_p()
sometimes says 'no' when it should say 'yes'
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
set/get_mempolicy manpages say that the memory allocation
policy is per process while reading the code and testing shows
that it's actually per thread. Here's a quick fix, which may
need to be improved to better explain that we're allocating
in the context of a thread within a process address space.
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Long ago, some page reworking moved this text to a somewhat
random location in the middle of the socket options list.
Move it to a sensible location, and at the same time,
rework the text to be a little clearer.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The manpage packet(7) currently states that:
"When you send packets it is enough to specify sll_family, sll_addr,
sll_halen, sll_ifindex."
This is incorrect: you also need to specify sll_protocol.
(The protocol specified when the socket is created is used for
filtering inbound packets, but not for constructing outbound
packets.)
I encountered this while researching a page for my website:
http://www.microhowto.info/howto/send_an_arbitrary_ethernet_frame_using_an_af_packet_socket_in_c.html
To empirically verify the behaviour I took my test code from the
above page then changed it to use different values for the third
argument to socket() and the sll_protocol field:
- socket created with ETH_P_ARP, packet sent with ETH_P_ARP:
packet sent with EtherType of ETH_P_ARP
- socket created with ETH_P_ARP, sll_protocol==0:
packet sent with EtherType of 0
- socket created with 0x88b5, sll_protocol==htons(ETH_P_ARP):
packet sent with EtherType of ETH_P_ARP
- socket created with ETH_P_ARP, sll_protocol==htons(0x88b5):
packet sent with EtherType of 0x88b5
This shows that leaving sll_protocol set to zero does not have
the desired effect and that it needs to be set to the desired
link-layer protocol.
There is code in the relevant kernel source file
(net/packet/af_packet.c) which appears to inspect the value of the
sll_protocol field and use it as the link-layer protocol number,
however I am not sufficiently familiar with this subsystem to be
fully confident of what is happening. The line in question is:
proto = saddr->sll_protocol;
In version 3.4 of the kernel this can be found in the functions
packet_snd and tpacket_snd. In version 2.6.26 it is in packet_sendmsg.
Below is a patch that adds sll_protocol to the list of required fields.
This may not be the whole truth, since it is not clear what role if any
sll_protocol, sll_halen or sll_addr would play when the socket type is
SOCK_RAW, however I'm confident it is more accurate than the page as it
stands at present.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
'cflags' is a bit mask of *zero* (not one) or more flags.
Reported-by: Laurence Gonsalves <laurence@xenomachina.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>