login
Search
On Sunday 14 October 2007 8:45:03 pm Theodore Tso wrote:Ok, I'll bite. If it's all "real" scsi, why does ioctl(SG_EMULATED_HOST) exist? exist if it's all "real" scsi? They're the same thing? Do you mean that on a system with both, going: ifconfig eth1 66.92.53.140 ifconfig ppp 192.168.0.42 Would be functionally equivalent to: ifconfig eth1 192.168.0.42 ifconfig ppp 66.92.53.140 So if on one boot the addresses are assigned the first way, and upon reboot they're assigned in the second way by exact the same set of commands... well that's not IMPORTANT, is it? (Or is it that everyone everywhere should use dhcp for everything, and static addressing is obsolete and no longer supported? Apparently dhcp addresses should be delivered by machines with only one network interface of any type...) This is my objection. Even when enumerating multiple devices of the same type is tricky, enumerating multiple devices of _different_ types should not be. There's a great big type indicator that is being _deliberately_ ignored, and large classes of devices (millions of laptops) where you know there's only going to be _one_ instance of a given type. By the way, ethernet cards contain a unique MAC address. Hard drives do not seem to, or if they do it's not being consistently exposed in a way I can find. This is sad. (No, reading data from the device to determine this gets us back to the "spinning up the external USB drive to find my root partition" gripe mentioned earlier.) Let me clarify: I'm talking about device enumeration. I've never had trouble enumerating a device that was _not_ routed through the scsi layer, largely because the systems I work with don't usually have more than one device of the same type. (There are millions of laptop and desktop devices out there where this is the common case. As I said, I may have four USB ports and the ability to plug hubs into them, but you can't add another SATA hard drive to my laptop without a soldering iron.) However, as soon as a device _is_ routed through the scsi layer (as PATA was a few versions back), it gets conflated with numerous other devices. This creates problems. SATA isn't hard to enmerate in my laptop, USB potentially is. Dumpting all the SATA devices into the same bucket with the USB devices makes both harder to enumerate. I have buckets of ignorance. It's why I ask questions. And down far enough all these devices are powered by electricity. Are we going to wind up with /dev/electric[1-999]? SATA != PATA != USB. But /dev/sda can be PATA, /dev/sdb SATA, and /dev/sdc USB. And they can move relative to each other. This didn't used to be the case. Why is it considered an improvement? I'm aware of this, and under the impression they're both modified gigabit ethernet at the PHY level. Should the hard drive become eth2? The spec may define the capability to hotplug, but your average laptop doesn't not offer the capability to hotplug anything into its SATA controllers. The hard drive is screwed in (due to the portability part of laptopness), all the controllers wired onto the motherboard are accounted for, none are exposed externally. What _is_ exposed externally is USB, and if you want to add an extra hard drive you can buy a cheap USB one at Fry's. In such a case, which is common, the first SATA hard drive is reliably the disk containing the root partition, and there's no need to stick a UUID in /etc/fstab. The problem is, "the first SATA hard drive" is not a stable identifier in a system where SATA and USB devices are dumped in the same bucket and given a big stir. Dumping SATA and USB devices into the same bucket (because they smell a bit like SCSI) is what I am objecting to. It was also possible to buy a hotplug PATA ide enclosure. So what? The vast majority of traditional IDE users happily ignored this, and went on with their lives. I remember the config option about enumerating onboard IDE controllers first. It didn't really matter what order they were enumerated in as long as it was controllable. Presumably if the primary SATA hard drive was /dev/sata and the slot with "secondary" in its name got /dev/satb, life would be good. And the presence or absence of /dev/satb wouldn't affect USB devices and such if they weren't in the same namespace. You plug it in somewhere else, it shows up somewhere else. This sounds familiar to old IDE users. :) How is it harder for udev to make a stable symlink for this drive that sometimes points to /dev/satb and sometimes to /dev/usb1? (Harder than a symlink that sometimes points to /dev/sdb and sometimes to /dev/sdd? You don't have persistent naming _now_, so the objection seems to be that maintaining the distinction between device types would not be a perfect solution in all cases. I agree. So?) Yup. And you've been able to make a network block device for years. They showed up as /dev/nd0, a distinct type of block device which you (and your scripts) could find. Now yet another way of doing the same thing is mixed into the same scsi bucket and given a stir... If my laptop's hard drive reliably showed up as /dev/sda every time, and I could count on that, I wouldn't be complaining about it. The entire problem is that it isn't guaranteed to do that, and thus /etc/fstab is a nightmare I can't edit. You could meet this definition of "the same" by having every block device in the system show up as /dev/block[a-z] no matter what type it was, and all the char devices show up as /dev/char[aa-zz], shuffle them all each reboot, and then have all the programs iterate through all of them any time they wanted something specific. I'm rather glad that /dev/ttyS0 and /dev/zero aren't easy to mix up. It's necessary for IBM big iron to do this. It's generally not necessary for laptops or embedded systems to do this if they distinguish between _types_ of devices, which is something they until recently did for the types of devices I was interested in, and something they _stopped_ doing when everything got merged into the scsi layer, and I consider this a regression. No, distinguishing between types of devices is not a perfect solution to device enumeration, but it was sufficient for all my use cases for many years, and would still be if the kernel still did it, and I'm not alone here. Last week I drove my laptop so deep into swap (with a "make -j" on qemu) that after half an hour trying to repaint my kmail window, it locked solid. Again. You'd think the oom killer would come to the rescue, but it didn't. Maybe Ubuntu disabled it. I have _2_gigs_ of ram in this sucker, on a stock Ubuntu 7.04 install (with the "upgrade all" tab pressed a few times), and yet I managed to make it swap itself to death one more time. Virtual memory isn't perfect. I've _always_ been able to come up with examples where it just doesn't work for me. This doesn't mean VM overcommit should be abolished, because it's useful more often than not. So you have a counterexample. Ok. I can't actually see how your counterexample would be worse off than it is now; just differently worse off. It does when I'm configuring the interfaces. And in the networking world I'm able to say that this local machine has a static IP that is not world-routable. It is separate, manually configured, I put it _right_here_, and I personally know that it's not going to move because I'm the one who put it there and I'm the only one who would move it. Over on the networking side of things I can "ifconfig lo 127.0.0.1" without first probing all the interfaces to figure out which one's loopback and which one's the wireless card. I note that the eth0 and eth1 names are dynamically assigned on a first come first serve basis (like scsi). This never causes me a problem because the driver loading order is constant, and once you figure out that eth0 is gigabit and eth1 is the 80211g it _stays_ that way across reboots, reliably. Yeah, it's a heuristic. Hands up everybody relying on such a heuristic in the real world. Possibly one solution here is to document that the SATA drivers load before any other scsi device, and the driver subsystem _waits_ for that to finish enumerating before trying any other kind of scsi device, with a barrier of some kind), and then any SATA devices present at boot time will reliably get those names in that order (no races, no variation) and anything after that is a separate problem. (Of course this would involve making it true if it currently isn't. It's still a mess to dump all sorts of different devices in the same namespace, but at least for the common case of a laptop with a SATA root partition this would let us get the UUID out of /etc/fstab). Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -
| Alan | Re: [RFC] Heads up on sys_fallocate() |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Paul Mundt | Re: 2.6.22-rc4-mm2 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [GIT]: Networking |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
