Re: kernel frameworks for jumbo frame
On Mon, 2019-03-11 at 04:37 -0400, John Franklin wrote: > On Mar 10, 2019, at 15:33, Gert Doering wrote: > > Hi, > > > > On Sun, Mar 10, 2019 at 12:14:54PM -0700, Brian Buhrow wrote: > > > hello. I'm not saying anything that anyone here doesn't already know, > > > but I'll add that Linux seems to have taken the position that all ethernet > > > interfaces should be called eth0, eth1, etc. > > > > This argument surprises me a bit, as Linux has moved *away* from doing > > exactly this a few years ago... > > Depending on who you ask, this was either poorly received by the community or > “has mixed reviews.” I’ve yet to meet someone who thought it was the best > thing ever. > As with everything, I'd expect some people to consider X better, some to consider Y better, and a few to take this opportunity to remind everyone that there's also an alternative of Z. I'd also expect a major group of neutral people who don't really care either way. What really brought major 'poor reception' is *change* rather than the idea itself. I think it's meaningful to distinguish between people who actually prefer Y over X because they think it's better, and people who don't like change from Y to X because it means they have to do 'unnecessary' work to adjust their systems and/or change their habits. Then, of course there would be some people who would actually consider this an opportunity to improve their setups. What I'm saying is that you can't expect neither wholly negative or wholly positive reception here. People who are unhappy/angry tend to be more verbose about it. Most of the people won't go out their way to praise interface naming solution even if they liked it. Most of the people won't really care as long as things work out of the box. One fun fact about the new naming scheme is that if you have USB wifi dongle, you can expect the name to depend on which port you plug it into. So much for consistent naming ;-). -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: Ethernet naming [was Re: kernel frameworks for jumbo frame]
On 11/03/2019 13:23, Mouse wrote: What I struggle to tell, regardles of OS, is if a device is physical or virtual (such as PPP, TAP or TUN). Why do you care? I'm having trouble thinking of a reason to care, and, actually, I'm not sure you _should_ be able to tell. Indeed, the concept we usually think of as a network interface is a virtualization, provided (by the driver and some pieces of MI kernel) atop the actual hardware. Generally you would want all physical interfaces to autoconfigure (ie DHCP, RA, etc). This is rarely true for virtual interfaces. On the flip side, you generally want to prefer DNS from a virtual interface (like say a VPN) when connected over a more general DNS such as from wired ethernet. So when you goto mouse.rejects.email.blah and it can resolve to a private IP (over VPN) or a public IP (over eth0) it will use the VPN. Running dhcpcd on all interfaces (for example) won't break anything, but equally it's a waste of potential resources. Also, I could argue whether ppp is virtual or not; it seems to me it's a defensible position that ppp, at least when connected to a real serial port, is as real an interface as any Ethernet, just using (very) different layers 1 and 2. When my serial ports are listed by ifconfig after booting single user I would agree they wouldn't be virtual. But they are not, so they are virtual. Roy
Ethernet naming [was Re: kernel frameworks for jumbo frame]
> What I struggle to tell, regardles of OS, is if a device is physical > or virtual (such as PPP, TAP or TUN). Why do you care? I'm having trouble thinking of a reason to care, and, actually, I'm not sure you _should_ be able to tell. Indeed, the concept we usually think of as a network interface is a virtualization, provided (by the driver and some pieces of MI kernel) atop the actual hardware. Also, I could argue whether ppp is virtual or not; it seems to me it's a defensible position that ppp, at least when connected to a real serial port, is as real an interface as any Ethernet, just using (very) different layers 1 and 2. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: kernel frameworks for jumbo frame
On 11/03/2019 08:37, John Franklin wrote: This is something I thought was solved *years ago* in the Linux world, and I don’t understand why udev/systemd had to break it. udev has changed nameing scheme at least twice in my memory. This is on top of any kernel changes in this area. Splitting eth0 vs wifi0 makes sense to me, as the inherent nature of the devices are fundamentally different. This actually makes little sense to me - as a developer. I can tell wifi from ethernet by virtue of the SSID property being present via ifconfig. What I struggle to tell, regardles of OS, is if a device is physical or virtual (such as PPP, TAP or TUN). On BSD, because the name cannot be changed, I can derive this. But a hard coded list of device names to special case is pretty bad really. Roy
Re: CURRENT broken on Raspberry Pi 2?
Might I suggest a reference count? RUN_ONCE() can initialize the mutex
around the counter, and then the counter can keep track of the init's and
fini's called, and only do the work on t
>he 0->1 edge and the 1->0 edge
>>> .
>>>
>>> You also need to destroy the mutex somewhen.
>>>
>>> RUN_ONCE needs to learn a bit more about life cycles.
>>
>> I made INIT_ONCE(9) and FINI_ONCE(9) with reference counter.
>> Is this OK like this?
>
>Hi,
>
>Thanks for working on this.
>
>At the moment your _{init,fini}_once are missing cv_broadcasts, but I
>wonder if we can merge _{run,init}_once and avoid duplicate code.
>
>I'm not sure if _fini_done should ever wait.
Added tech-kern.
I fixed. thanks.
we need kernel version bump due to changing once_t and deleting _run_once().
cvs -q diff -aup sys/once.h kern/subr_once.c
Index: sys/once.h
===
RCS file: /src/cvs/cvsroot-netbsd/src/sys/sys/once.h,v
retrieving revision 1.6
diff -a -u -p -r1.6 once.h
--- sys/once.h 3 Mar 2018 19:21:59 - 1.6
+++ sys/once.h 11 Mar 2019 10:25:18 -
@@ -31,23 +31,29 @@
#define_SYS_ONCE_H_
typedef struct {
- unsigned o_status;
int o_error;
+ uint16_t o_refcnt;
+ uint16_t o_status;
#defineONCE_VIRGIN 0
#defineONCE_RUNNING1
#defineONCE_DONE 2
} once_t;
void once_init(void);
-int _run_once(once_t *, int (*)(void));
+int _init_once(once_t *, int (*)(void));
+void _fini_once(once_t *, void (*)(void));
#defineONCE_DECL(o) \
- once_t (o) __read_mostly = { \
+ once_t (o) = { \
.o_status = 0, \
+ .o_refcnt = 0, \
};
#defineRUN_ONCE(o, fn) \
(__predict_true((o)->o_status == ONCE_DONE) ? \
- ((o)->o_error) : _run_once((o), (fn)))
+ ((o)->o_error) : _init_once((o), (fn)))
+
+#defineINIT_ONCE(o, fn)_init_once((o), (fn))
+#defineFINI_ONCE(o, fn)_fini_once((o), (fn))
#endif /* _SYS_ONCE_H_ */
Index: kern/subr_once.c
===
RCS file: /src/cvs/cvsroot-netbsd/src/sys/kern/subr_once.c,v
retrieving revision 1.6
diff -a -u -p -r1.6 subr_once.c
--- kern/subr_once.c15 Mar 2009 17:14:40 - 1.6
+++ kern/subr_once.c11 Mar 2019 10:33:37 -
@@ -48,13 +48,17 @@ once_init(void)
}
int
-_run_once(once_t *o, int (*fn)(void))
+_init_once(once_t *o, int (*fn)(void))
{
-
/* Fastpath handled by RUN_ONCE() */
+ int error;
+
mutex_enter(&oncemtx);
- if (o->o_status == ONCE_VIRGIN) {
+ while (o->o_status == ONCE_RUNNING)
+ cv_wait(&oncecv, &oncemtx);
+
+ if (o->o_refcnt++ == 0) {
o->o_status = ONCE_RUNNING;
mutex_exit(&oncemtx);
o->o_error = fn();
@@ -62,10 +66,34 @@ _run_once(once_t *o, int (*fn)(void))
o->o_status = ONCE_DONE;
cv_broadcast(&oncecv);
}
- while (o->o_status != ONCE_DONE)
+ KASSERT(o->o_refcnt != 0); /* detect overflow */
+
+ while (o->o_status == ONCE_RUNNING)
cv_wait(&oncecv, &oncemtx);
+ error = o->o_error;
mutex_exit(&oncemtx);
- KASSERT(o->o_status == ONCE_DONE);
- return o->o_error;
+ return error;
+}
+
+void
+_fini_once(once_t *o, void (*fn)(void))
+{
+ mutex_enter(&oncemtx);
+ while (o->o_status == ONCE_RUNNING)
+ cv_wait(&oncecv, &oncemtx);
+
+ KASSERT(o->o_refcnt != 0); /* we need to call _init_once() once */
+ if (--o->o_refcnt == 0) {
+ o->o_status = ONCE_RUNNING;
+ mutex_exit(&oncemtx);
+ fn();
+ mutex_enter(&oncemtx);
+ o->o_status = ONCE_VIRGIN;
+ cv_broadcast(&oncecv);
+ }
+
+ while (o->o_status == ONCE_RUNNING)
+ cv_wait(&oncecv, &oncemtx);
+ mutex_exit(&oncemtx);
}
--
ryo shimizu
Re: svr4, again
I'd rather not - on the rare occasions when I boot up my pmax, I do actually have a couple of Ultrix binaries I run. If I couldn't, about 5 years of my academic work would be lost to me (because Digital's packaged applications couldn't export to any portable format except print-analogues like Postscript). What needs to be done to Ultrix compatibility to keep it alive? I will admit to not looking at it in at least a decade, but it was pretty darned small, wasn't it? On Sat, Mar 09, 2019 at 10:56:34AM -0500, Christos Zoulas wrote: > Let's retire them. > > christos > > > On Mar 9, 2019, at 5:28 AM, Maxime Villard wrote: > > > > Re-reading this thread - which was initially about SVR4 but which diverged > > in > > all directions -, I see there were talks about retiring COMPAT_ULTRIX and > > COMPAT_OSF1, because these were of questionable utility, in addition to > > being > > clear dead wood (in terms of use case, commits in these areas, and ability > > to > > test changes). > > > > Does anyone have anything to say? -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but because it is right." --Andrei Sakharov
Re: kernel frameworks for jumbo frame
On Sun, Mar 10, 2019 at 08:33:43PM +0100, Gert Doering wrote: [...] > On a system that only has one ethernet card, it's highly annoying > that I have to figure out if this is a "em0" or "igb0" - or an > "eno1" vs. "enp0s25" (both "onboard ethernet 0", but BIOS tables > leading udev to believing the second one isn't). So "eth0, always" > would be very convenient. Or possibly "eth0" for "wired ethernet" > and "wifi0" for wireless - as that's a common scenario. Nowadays I'm pretty sure that so-called "predictable interface names", dependent on physical layout of mainboard was a terrible mistake. Hardware itself doesn't guarantee consistent and dependable behaviour, especially between different vendors. Some examples: onboard ethernet card on my mainboard was identified as enp0s25 but inserting SERIAL controller (four RS232 ports) into PCIe slot lead to renaming onboard interface to... enp16s0. Why? I have no clue. Friend of mine has two-ports Intel card. Internally implemented as two different PCIe functions and available as... enp0s0f0 and enp0s0f1d1 (but it is subject to change between different kernel versions 8-0). With a brand-new mobo there is no chance to guess interface name without test run. Classic Linux behaviour has two possibilities: simply "eth0" in any case or interface renaming based on MAC-addresses (fortunately MAC addr is usually known). BSD names also gives us a chance - usually we know something about network card manufacturer. -- Piotr 'aniou' Meyer
Re: kernel frameworks for jumbo frame
On Mar 10, 2019, at 15:33, Gert Doering wrote: > > Hi, > > On Sun, Mar 10, 2019 at 12:14:54PM -0700, Brian Buhrow wrote: >> hello. I'm not saying anything that anyone here doesn't already know, >> but I'll add that Linux seems to have taken the position that all ethernet >> interfaces should be called eth0, eth1, etc. > > This argument surprises me a bit, as Linux has moved *away* from doing > exactly this a few years ago... Depending on who you ask, this was either poorly received by the community or “has mixed reviews.” I’ve yet to meet someone who thought it was the best thing ever. That said, when I worked more with NetBSD I had little difficulties working with igb0, and the like. Perhaps because NetBSD feels like I’m working closer to the hardware than Linux, it felt more natural to specify the driver as part of the network device name. Or maybe because I was using NetBSD before I was using Linux, it was just how things worked. When I did start using Linux circa 2000, the “a NIC is a NIC” naming abstraction made a lot of sense. (Yes, I know “a NIC is a NIC” is too facile when you get to the nitty gritty details. There are different features and status exposed via different drivers, depending on the capabilities of the chip — checksum offloading, max frame size, etc — all handled via the driver settings and ioctl. But, for the basics and simply getting the name of the device, the abstraction works well.) > Personally, I'm a bit torn on what is "the best" thing. > > On a system that only has one ethernet card, it's highly annoying > that I have to figure out if this is a "em0" or "igb0" - or an > "eno1" vs. "enp0s25" (both "onboard ethernet 0", but BIOS tables > leading udev to believing the second one isn't). So "eth0, always" > would be very convenient. Or possibly "eth0" for "wired ethernet" > and "wifi0" for wireless - as that's a common scenario. > > For a system with multiple ethernet cards (server with frontend/backend > networks, or firewals, or routers) naming *stability* is a must - having > "em0" and "em1" swap their numbers at upgrading is as disruptive as > "eth0 and eth1 get swapped because one card had to be changed and the > other driver loads first". So here, something based on bus numbering > might be best - stability trumping convenience... This is something I thought was solved *years ago* in the Linux world, and I don’t understand why udev/systemd had to break it. The first time a system boots, the kernel assigned network cards in the order discovered eth0, eth1…ethX, and recorded the device ID to a MAC address mapping in a udev rule. On subsequent boots, the kernel through the udev rules would retain the same device IDs, even if the kernel discovered them in a different order. If a card is replaced, then the new one would get the next ID by default. If an admin wants a certain order, the rules can be changed. In my experience, it worked fine for the simple case of desktops and laptops with one NIC, it provided reasonable defaults and stability in multi-NIC servers, and allowed for arbitrarily complex situations. It’s only in the infrequent case of a replacement NIC that would force an admin to find and update the udev rules (he’s in there already updating the hardware!), which IMHO, falls under Works As Intended. Splitting eth0 vs wifi0 makes sense to me, as the inherent nature of the devices are fundamentally different. jf -- John Franklin frank...@elfie.org smime.p7s Description: S/MIME cryptographic signature
