From: Greg KH <greg@kroah.com> To: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: udev and devfs - The final word Date: Tue, 30 Dec 2003 16:29:42 -0800 [thread overview] Message-ID: <20031231002942.GB2875@kroah.com> (raw) (This text can be found at kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs for those who want to link to it. I'll also update it with info based on the thread I know is going to spawn from this post...) Executive summary for those too lazy to read this whole thing: I don't care about devfs, and I don't want to talk about it at all anymore. If you love devfs, fine, I'm not trying to tell anyone what to do. But you really should be looking into using udev instead. All further email messages sent to me about devfs will be gladly ignored. First off, some background. For a description of udev, and what it's original design goals were, please see the OLS 2003 paper on udev, available at: <http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf> and the slides for the talk, available at: <http://www.kroah.com/linux/talks/ols_2003_udev_talk/> The OLS paper can also be found in the docs/ directory of the udev tarball, available on kernel.org in the /pub/linux/utils/kernel/hotplug/ directory. In that OLS paper, I described the current situation of a static /dev and the current problems that a number of people have with it. I also detailed how devfs tries to solve a number of these problems. In hindsight, I should have never mentioned the word, devfs, when talking about udev. I did so only because it seemed like a good place to start with. Most people understood what devfs is, and what it does. To compare udev against it, showing how udev was more powerful, and a more complete solution to the problems people were having, seemed like a natural comparison to me. But no more. I hereby never want to compare devfs and udev again. With the exception of this message... The Problems: 1) A static /dev is unwieldy and big. It would be nice to only show the /dev entries for the devices we actually have running in the system. 2) We are (well, were) running out of major and minor numbers for devices. 3) Users want a way to name devices in a persistent fashion (i.e. "This disk here, must _always_ be called "boot_disk" no matter where in the scsi tree I put it", or "This USB camera must always be called "camera" no matter if I have other USB scsi devices plugged in or not.") 4) Userspace programs want to know when devices are created or removed, and what /dev entry is associated with them. The constraints: 1) No policy in the kernel! 2) Follow standards (like the LSB) 3) must be small so embedded devices will use it. So, how does devfs stack up to the above problems and constraints: Problems: 1) devfs only shows the dev entries for the devices in the system. 2) devfs does not handle the need for dynamic major/minor numbers 3) devfs does not provide a way to name devices in a persistent fashion. 4) devfs does provide a deamon that userspace programs can hook into to listen to see what devices are being created or removed. Constraints: 1) devfs forces the devfs naming policy into the kernel. If you don't like this naming scheme, tough. 2) devfs does not follow the LSB device naming standard. 3) devfs is small, and embedded devices use it. However it is implemented in non-pagable memory. Oh yeah, and there are the insolvable race conditions with the devfs implementation in the kernel, but I'm not going to talk about them right now, sorry. See the linux-kernel archives if you care about them (and if you use devfs, you should care...) So devfs is 2 for 7, ignoring the kernel races. And now for udev: Problems: 1) using udev, the /dev tree only is populated for the devices that are currently present in the system. 2) udev does not care about the major/minor number schemes. If the kernel tomorrow switches to randomly assign major and minor numbers to different devices, it would work just fine (this is exactly what I am proposing to do in 2.7...) 3) This is the main reason udev is around. It provides the ability to name devices in a persistent manner. More on that below. 4) udev emits D-BUS messages so that any other userspace program (like HAL) can listen to see what devices are created or removed. It also allows userspace programs to query it's database to see what devices are present and what they are currently named as (providing a pointer into the sysfs tree for that specific device node.) Constraints: 1) udev moves _all_ naming policies out of the kernel and into userspace. 2) udev defaults to using the LSB device naming standard. If users want to deviate away from this standard (for example when naming some devices in a persistent manner), it is easily possible to do so. 3) udev is small (49Kb binary) and is entirely in userspace, which is swapable, and doesn't have to be running at all times. Nice, 7 out of 7 for udev. Makes you think the problems and constraints were picked by a udev developer, right? No, the problems and constraints are ones I've seen over the years and so udev, along with the kernel driver model and sysfs, were created to solve these real problems. I also have had the luxury to see the problems that the current devfs implementation has, and have taken the time to work out something that does not have those same problems. So by just looking at the above descriptions, everyone should instantly realize that udev is far better than devfs and start helping out udev development, right? Oh, you want more info, ok... Back in May 2003 I released a very tiny version of udev that implemented everything that devfs currently does, in about 6Kb of userspace code: http://marc.theaimsgroup.com/?l=linux-kernel&m=105003185331553 Yes, that's right, 6Kb. So, you are asking, why are you still working on udev if it did everything devfs did back in May 2003? That's because just managing static device nodes based on what the kernel calls the devices is _not_ the primary goal of udev. It's just a tiny side affect of it's primary goal, the ability to never worry about major/minor number assignments and provide the ability to achieve persistent device names if wanted. All the people wanting to bring up the udev vs. devfs argument go back and read the previous paragraph. Yes, all Gentoo users who keep filling up my inbox with smoking emails, I mean you. So, how well does udev solve it's goals: Prevent users from ever worrying about major/minor numbers And here you were, not knowing you ever needed to worry about major/minor numbers in the first place, right? Ah, I see you haven't plugged in 2 USB printers and tried to figure out which printer was which /dev entry? Or plugged in 4000 SCSI disks and tried to figure out how to access that 3642nd disk and what it was called in /dev. Or plugged in a USB camera and a USB flash drive and then tried to download the pictures off of the flash drive by accident? As the above scenarios show, both desktop users and big iron users both need to not worry about which device is assigned to what major/minor device. udev doesn't care what major/minor number is assigned to a device. It merely takes the numbers that the kernel says it assigned to the device and creates a device node based on it, which the user can then use (if you don't understand the whole major/minor to device node issue, or even what a device node is, trust me, you don't really want to, go install udev and don't worry about it...) As stated above, if the kernel decides to start randomly assigning major numbers to all devices, then udev will still work just fine. Provide a persistent device naming solution: Lots of people want to assign a specific name that they can talk to a device to, no matter where it is in the system, or what order they plugged the device in. USB printers, SCSI disks, PCI sound cards, Firewire disks, USB mice, and lots of other devices all need to be assigned a name in a consistent manner (udev doesn't handle network devices, naming them is already a solved solution, using nameif). udev allows users to create simple rules to describe what device to name. If users want to call a program running a large database half-way around the world, asking it what to name this device, it can. We don't put the naming database into the kernel (like other Unix variants have), everything is in userspace, and easily accessible. You can even run a perl script to name your device if you are that crazy... For more information on how to create udev rules to name devices, please see the udev man page, and look at the example udev rules that ship with the tarball. So, convinced already why you should use udev instead of devfs? No. Ok, fine, I'm not forcing you to abandon your bloated, stifling policy, nonextensible, end of life feature if you don't want to. But please don't bother me about it either, I don't care about devfs, only about udev. This is my last posting about this topic, all further emails sent to me about why devfs is wonderful, and why are you making fun of this wonderful, stable gift from the gods, will be gleefully ignored and possibly posted in a public place where others can see. thanks, greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com> To: linux-hotplug-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: udev and devfs - The final word Date: Wed, 31 Dec 2003 00:29:42 +0000 [thread overview] Message-ID: <20031231002942.GB2875@kroah.com> (raw) (This text can be found at kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs for those who want to link to it. I'll also update it with info based on the thread I know is going to spawn from this post...) Executive summary for those too lazy to read this whole thing: I don't care about devfs, and I don't want to talk about it at all anymore. If you love devfs, fine, I'm not trying to tell anyone what to do. But you really should be looking into using udev instead. All further email messages sent to me about devfs will be gladly ignored. First off, some background. For a description of udev, and what it's original design goals were, please see the OLS 2003 paper on udev, available at: <http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf> and the slides for the talk, available at: <http://www.kroah.com/linux/talks/ols_2003_udev_talk/> The OLS paper can also be found in the docs/ directory of the udev tarball, available on kernel.org in the /pub/linux/utils/kernel/hotplug/ directory. In that OLS paper, I described the current situation of a static /dev and the current problems that a number of people have with it. I also detailed how devfs tries to solve a number of these problems. In hindsight, I should have never mentioned the word, devfs, when talking about udev. I did so only because it seemed like a good place to start with. Most people understood what devfs is, and what it does. To compare udev against it, showing how udev was more powerful, and a more complete solution to the problems people were having, seemed like a natural comparison to me. But no more. I hereby never want to compare devfs and udev again. With the exception of this message... The Problems: 1) A static /dev is unwieldy and big. It would be nice to only show the /dev entries for the devices we actually have running in the system. 2) We are (well, were) running out of major and minor numbers for devices. 3) Users want a way to name devices in a persistent fashion (i.e. "This disk here, must _always_ be called "boot_disk" no matter where in the scsi tree I put it", or "This USB camera must always be called "camera" no matter if I have other USB scsi devices plugged in or not.") 4) Userspace programs want to know when devices are created or removed, and what /dev entry is associated with them. The constraints: 1) No policy in the kernel! 2) Follow standards (like the LSB) 3) must be small so embedded devices will use it. So, how does devfs stack up to the above problems and constraints: Problems: 1) devfs only shows the dev entries for the devices in the system. 2) devfs does not handle the need for dynamic major/minor numbers 3) devfs does not provide a way to name devices in a persistent fashion. 4) devfs does provide a deamon that userspace programs can hook into to listen to see what devices are being created or removed. Constraints: 1) devfs forces the devfs naming policy into the kernel. If you don't like this naming scheme, tough. 2) devfs does not follow the LSB device naming standard. 3) devfs is small, and embedded devices use it. However it is implemented in non-pagable memory. Oh yeah, and there are the insolvable race conditions with the devfs implementation in the kernel, but I'm not going to talk about them right now, sorry. See the linux-kernel archives if you care about them (and if you use devfs, you should care...) So devfs is 2 for 7, ignoring the kernel races. And now for udev: Problems: 1) using udev, the /dev tree only is populated for the devices that are currently present in the system. 2) udev does not care about the major/minor number schemes. If the kernel tomorrow switches to randomly assign major and minor numbers to different devices, it would work just fine (this is exactly what I am proposing to do in 2.7...) 3) This is the main reason udev is around. It provides the ability to name devices in a persistent manner. More on that below. 4) udev emits D-BUS messages so that any other userspace program (like HAL) can listen to see what devices are created or removed. It also allows userspace programs to query it's database to see what devices are present and what they are currently named as (providing a pointer into the sysfs tree for that specific device node.) Constraints: 1) udev moves _all_ naming policies out of the kernel and into userspace. 2) udev defaults to using the LSB device naming standard. If users want to deviate away from this standard (for example when naming some devices in a persistent manner), it is easily possible to do so. 3) udev is small (49Kb binary) and is entirely in userspace, which is swapable, and doesn't have to be running at all times. Nice, 7 out of 7 for udev. Makes you think the problems and constraints were picked by a udev developer, right? No, the problems and constraints are ones I've seen over the years and so udev, along with the kernel driver model and sysfs, were created to solve these real problems. I also have had the luxury to see the problems that the current devfs implementation has, and have taken the time to work out something that does not have those same problems. So by just looking at the above descriptions, everyone should instantly realize that udev is far better than devfs and start helping out udev development, right? Oh, you want more info, ok... Back in May 2003 I released a very tiny version of udev that implemented everything that devfs currently does, in about 6Kb of userspace code: http://marc.theaimsgroup.com/?l=linux-kernel&m\x105003185331553 Yes, that's right, 6Kb. So, you are asking, why are you still working on udev if it did everything devfs did back in May 2003? That's because just managing static device nodes based on what the kernel calls the devices is _not_ the primary goal of udev. It's just a tiny side affect of it's primary goal, the ability to never worry about major/minor number assignments and provide the ability to achieve persistent device names if wanted. All the people wanting to bring up the udev vs. devfs argument go back and read the previous paragraph. Yes, all Gentoo users who keep filling up my inbox with smoking emails, I mean you. So, how well does udev solve it's goals: Prevent users from ever worrying about major/minor numbers And here you were, not knowing you ever needed to worry about major/minor numbers in the first place, right? Ah, I see you haven't plugged in 2 USB printers and tried to figure out which printer was which /dev entry? Or plugged in 4000 SCSI disks and tried to figure out how to access that 3642nd disk and what it was called in /dev. Or plugged in a USB camera and a USB flash drive and then tried to download the pictures off of the flash drive by accident? As the above scenarios show, both desktop users and big iron users both need to not worry about which device is assigned to what major/minor device. udev doesn't care what major/minor number is assigned to a device. It merely takes the numbers that the kernel says it assigned to the device and creates a device node based on it, which the user can then use (if you don't understand the whole major/minor to device node issue, or even what a device node is, trust me, you don't really want to, go install udev and don't worry about it...) As stated above, if the kernel decides to start randomly assigning major numbers to all devices, then udev will still work just fine. Provide a persistent device naming solution: Lots of people want to assign a specific name that they can talk to a device to, no matter where it is in the system, or what order they plugged the device in. USB printers, SCSI disks, PCI sound cards, Firewire disks, USB mice, and lots of other devices all need to be assigned a name in a consistent manner (udev doesn't handle network devices, naming them is already a solved solution, using nameif). udev allows users to create simple rules to describe what device to name. If users want to call a program running a large database half-way around the world, asking it what to name this device, it can. We don't put the naming database into the kernel (like other Unix variants have), everything is in userspace, and easily accessible. You can even run a perl script to name your device if you are that crazy... For more information on how to create udev rules to name devices, please see the udev man page, and look at the example udev rules that ship with the tarball. So, convinced already why you should use udev instead of devfs? No. Ok, fine, I'm not forcing you to abandon your bloated, stifling policy, nonextensible, end of life feature if you don't want to. But please don't bother me about it either, I don't care about devfs, only about udev. This is my last posting about this topic, all further emails sent to me about why devfs is wonderful, and why are you making fun of this wonderful, stable gift from the gods, will be gleefully ignored and possibly posted in a public place where others can see. thanks, greg k-h ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next reply other threads:[~2003-12-31 0:29 UTC|newest] Thread overview: 177+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-12-31 0:29 Greg KH [this message] 2003-12-31 0:29 ` udev and devfs - The final word Greg KH 2003-12-31 0:46 ` Johannes Erdfelt 2003-12-31 0:53 ` Prakash K. Cheemplavam 2003-12-31 0:53 ` Prakash K. Cheemplavam 2003-12-31 19:17 ` Greg KH 2003-12-31 19:17 ` Greg KH 2004-01-02 16:45 ` Shawn 2004-01-02 16:45 ` Shawn 2003-12-31 12:43 ` Paulo Marques 2004-01-01 1:18 ` Helge Hafting 2004-01-01 1:18 ` Helge Hafting 2004-01-03 5:59 ` Greg KH 2004-01-03 5:59 ` Greg KH 2004-01-03 15:22 ` Helge Hafting 2004-01-03 15:22 ` Helge Hafting 2004-01-03 21:18 ` viro 2004-01-03 21:18 ` viro 2004-01-03 22:11 ` Greg KH 2004-01-03 22:11 ` Greg KH [not found] ` <20040103140140.3b848e9f.witukind@nsbm.kicks-ass.org> 2004-01-03 22:16 ` Greg KH 2004-01-03 22:16 ` Greg KH 2004-01-03 22:33 ` Christoph Hellwig 2004-01-03 22:33 ` Christoph Hellwig 2004-01-02 17:54 ` Andreas Jellinghaus 2004-01-02 18:19 ` Shawn 2004-03-29 15:38 ` Shawn 2004-03-29 15:39 ` Greg KH 2004-03-29 15:40 ` Helge Hafting 2004-03-29 15:40 ` Greg KH 2004-03-29 15:40 ` Greg KH 2004-03-29 15:40 ` viro 2004-03-29 15:40 ` Christoph Hellwig [not found] <18Cz7-7Ep-7@gated-at.bofh.it> 2003-12-31 3:05 ` Pascal Schmidt 2003-12-31 19:23 ` Greg KH 2003-12-31 20:19 ` Rob Love 2003-12-31 22:01 ` Nathan Conrad 2003-12-31 22:20 ` Rob Love 2003-12-31 21:45 ` Tommi Virtanen 2003-12-31 23:10 ` Rob Love 2003-12-31 21:52 ` Tommi Virtanen 2004-01-02 0:17 ` Hollis Blanchard 2004-01-02 0:36 ` viro 2004-01-03 6:04 ` Greg KH 2003-12-31 22:55 ` viro 2003-12-31 23:05 ` Rob Love 2003-12-31 23:48 ` Andreas Dilger 2004-01-07 10:15 ` Olaf Hering 2004-01-07 11:18 ` viro 2004-01-07 13:00 ` Olaf Hering 2004-01-07 13:26 ` viro 2004-01-07 13:27 ` Olaf Hering 2004-01-01 0:15 ` Andries Brouwer 2004-01-01 0:31 ` Rob Love 2004-01-01 12:34 ` Rob Landley 2004-01-01 15:22 ` Rob Love 2004-01-01 15:48 ` Andries Brouwer 2004-01-01 15:54 ` Rob Love 2004-01-02 20:42 ` Linus Torvalds 2004-01-03 3:00 ` Andries Brouwer 2004-01-03 4:46 ` Linus Torvalds 2004-01-03 13:10 ` Andries Brouwer 2004-01-03 22:27 ` Linus Torvalds 2004-01-03 23:08 ` Andries Brouwer 2004-01-04 1:16 ` Mark Mielke 2004-01-04 1:54 ` Valdis.Kletnieks 2004-01-04 18:44 ` Mark Mielke 2004-01-04 2:09 ` Linus Torvalds 2004-01-04 2:49 ` Andries Brouwer 2004-01-04 3:04 ` Linus Torvalds 2004-01-04 13:21 ` Andries Brouwer 2004-01-04 21:05 ` Linus Torvalds 2004-01-04 22:01 ` Andries Brouwer 2004-01-04 22:37 ` viro 2004-01-05 1:02 ` Mark Mielke 2004-01-05 2:24 ` Valdis.Kletnieks 2004-01-05 2:29 ` Andries Brouwer 2004-01-05 3:42 ` viro 2004-01-04 22:37 ` Helge Hafting 2004-01-04 23:35 ` Valdis.Kletnieks 2004-01-05 1:43 ` Jeremy Maitin-Shepard 2004-01-05 1:58 ` viro 2004-01-05 2:12 ` Jeremy Maitin-Shepard 2004-01-05 2:52 ` Linus Torvalds 2004-01-05 3:06 ` David Lang 2004-01-05 3:48 ` Rob Landley 2004-01-05 4:52 ` Trond Myklebust 2004-01-05 15:13 ` Mark Mielke 2004-01-05 16:36 ` Andreas Schwab 2004-01-05 22:18 ` Mark Mielke 2004-01-05 3:07 ` Daniel Jacobowitz 2004-01-05 3:33 ` Linus Torvalds 2004-01-05 3:50 ` viro 2004-01-05 4:02 ` Linus Torvalds 2004-01-05 4:38 ` viro 2004-01-05 4:52 ` Linus Torvalds 2004-01-05 6:11 ` viro 2004-01-05 7:47 ` Greg KH 2004-01-05 11:15 ` Vojtech Pavlik 2004-01-05 20:11 ` Theodore Ts'o 2004-01-05 21:06 ` Vojtech Pavlik 2004-01-05 22:22 ` Theodore Ts'o 2004-01-06 0:14 ` Rob Landley 2004-01-11 22:12 ` Ed L Cashin 2004-01-05 5:26 ` Eric W. Biederman 2004-01-05 7:39 ` Greg KH 2004-01-07 9:57 ` Pavel Machek 2004-01-05 12:27 ` Andries Brouwer 2004-01-05 16:13 ` Linus Torvalds 2004-01-05 17:29 ` Vojtech Pavlik 2004-01-05 17:33 ` Linus Torvalds 2004-01-05 17:52 ` Davide Libenzi 2004-01-05 18:03 ` Linus Torvalds 2004-01-05 18:09 ` Hugo Mills 2004-01-05 19:10 ` Paul Rolland 2004-01-05 19:52 ` Andries Brouwer 2004-01-05 20:38 ` Linus Torvalds 2004-01-05 22:17 ` Shawn 2004-01-05 22:25 ` Mark Mielke 2004-01-05 23:05 ` Shawn 2004-01-05 23:23 ` Shawn 2004-01-06 0:43 ` Greg KH 2004-01-06 0:53 ` Shawn 2004-01-05 23:13 ` Andries Brouwer 2004-01-05 23:32 ` Linus Torvalds 2004-01-06 0:59 ` viro 2004-01-06 1:17 ` Linus Torvalds 2004-01-06 4:28 ` viro 2004-01-06 5:07 ` Linus Torvalds 2004-01-06 1:06 ` Andries Brouwer 2004-01-06 15:00 ` Mark Mielke 2004-01-06 0:00 ` Greg KH 2004-01-06 1:41 ` Andries Brouwer 2004-01-07 17:14 ` Greg KH 2004-01-06 0:31 ` Rob Landley 2004-01-06 7:14 ` Vojtech Pavlik 2004-01-05 7:44 ` James H. Cloos Jr. 2004-01-05 7:45 ` Nigel Cunningham 2004-01-05 11:01 ` Robin Rosenberg 2004-01-05 12:39 ` Nigel Cunningham 2004-01-07 13:39 ` Robin Rosenberg 2004-01-07 17:16 ` Nigel Cunningham 2004-01-05 9:06 ` Valdis.Kletnieks 2004-01-05 4:15 ` Peter Chubb 2004-01-05 4:42 ` Linus Torvalds 2004-01-01 19:43 ` Kai Henningsen 2004-01-02 7:26 ` Rob Landley 2004-01-04 8:57 ` Greg KH 2004-01-04 9:43 ` Rob Landley 2004-01-02 0:17 ` Maciej Zenczykowski [not found] ` <20040102103104.GA28168@mark.mielke.cc> 2004-01-03 6:07 ` Greg KH 2004-01-03 6:51 ` Valdis.Kletnieks 2004-01-03 11:57 ` Ian Kent 2004-01-03 22:08 ` Greg KH 2004-01-07 10:23 ` Olaf Hering 2004-01-01 23:14 ` Rob 2004-01-02 3:53 ` Tyler Hall 2004-01-01 16:17 ` Pascal Schmidt 2004-01-01 20:03 ` Greg KH [not found] <fa.af64864.ugabhg@ifi.uio.no> [not found] ` <fa.de7jae9.1jk0pjt@ifi.uio.no> 2003-12-31 22:17 ` walt 2004-01-01 2:03 ` Martin Schlemmer 2004-01-01 2:05 ` Martin Schlemmer 2004-01-01 16:59 Shaheed [not found] <fa.flhsork.uka2hg@ifi.uio.no> [not found] ` <fa.hv9hpq7.1l1q9p3@ifi.uio.no> 2004-01-01 19:53 ` walt 2004-01-01 21:53 ` Martin Schlemmer 2004-01-06 1:20 Paul Zimmerman 2004-01-08 13:05 "Andrey Borzenkov" 2004-01-08 13:53 "Andrey Borzenkov" 2004-01-08 15:40 ` Ian Kent 2004-01-08 17:26 ` Diego Calleja 2004-01-08 19:25 ` Andrey Borzenkov 2004-01-08 22:40 ` Alex Goddard 2004-01-09 7:03 ` "Andrey Borzenkov" 2004-01-08 18:14 ` Alex Goddard 2004-01-08 18:35 ` Alex Goddard 2004-01-08 19:22 ` Andrey Borzenkov 2004-01-09 8:51 ` Helge Hafting
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20031231002942.GB2875@kroah.com \ --to=greg@kroah.com \ --cc=linux-hotplug-devel@lists.sourceforge.net \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.