<klange>
ay, still up and still responding to pings 64 bytes from 192.168.11.39: icmp_seq=1 ttl=64 time=0.506 ms
trufas has joined #osdev
<kazinsal>
I feel like the "oh no sda changed" problem is one that can be solved by simply not overloading the shit out of device names
<kazinsal>
like that's specifically a problem of "sd" which originally meant "scsi disk" being now applied to "everything that isn't PATA or NVMe-native"
<heat>
what if you have two network interfaces(eth0 and eth1) and a bunch of network configuration on eth0
<heat>
imagine they switch?
<heat>
oops?
<kazinsal>
establishing a static mapping of hardware MAC address to interface resolves that
<kazinsal>
or going with the consistent device naming scheme that some distros use
<heat>
you can also get IDs for disks and partitions
<heat>
such that usually fstab only uses UUIDs
<heat>
doesn't make it less dumb
<kazinsal>
the issue of "user left a thumb drive in and now sda is a usb disk and init is having a freakout" is a separate one from "the user fucked around with the insides of the machine and now things don't work right"
<kazinsal>
the former is preventable by separating different device types
<kazinsal>
the latter is *mitigated* by enumerating devices in a logical consistent way where possible, but preventing a user from mucking around inside their system and fragging their interface configs is a complex can of worms that some would argue is not actually a kernel problem
<kazinsal>
to paraphrase torvalds, kernel changes should not break user space
<kazinsal>
but user changes breaking user space is just a user problem
<kazinsal>
if you called Cisco TAC because you moved some modules in a router around and your configs don't work anymore they're going to tell you to put the modules back where they were
<kazinsal>
it's not IOS's fault that the user started unscrewing things
<kazinsal>
as soon as you start yanking bits out of a machine, no matter what kind of machine it is, your known hardware configuration is invalid
<heat>
and maybe the best solution is to not have such simple device names
<kazinsal>
disk names definitely should be smarter
<heat>
qualify them based on the bus and bus address + IDs
<heat>
like windows does afaik
<kazinsal>
instead of hd* and sd* it should be something like ata*/sata*/nvme*/usbdisk*
<heat>
there's nvme
<kazinsal>
and ethernet should enumerate starting with onboard devices and then going down the PCIe tree
<heat>
yes but that's not how device enumeration works
<kazinsal>
linux's device enumeration is byzantine
<kazinsal>
and not in a historically fascinating demolished wonders of the world way
<heat>
buses enumarate devices based on the internal bus structure and put them on a list/tree, then when drivers are initialised the bus driver dooes probe() on every compatible dev
<heat>
which is sane
<kazinsal>
imo USB ethernets are one of those things that should be handled as a separate and expected to be temporary component
<kazinsal>
since they're designed to be removed and added on the fly, configuring them *last* makes the most sense to me
<kazinsal>
and flagging them as such
<kazinsal>
eg. usbeth*
<kazinsal>
or because unix nerds like short incomprehensible names for everything, enu*
<heat>
lol
<moon-child>
I wonder what creatd that tendency
<heat>
that's BSD
<heat>
the intel ethernet driver is called em
<klange>
In the original Unix days, it was just lack of space.
<kazinsal>
the udev/consistent device naming format is all afuck
<moon-child>
apparently an early c compiler limited identifiers to 5 chars or so
<moon-child>
it wouldn't error if you had a longer identifier, it would just ignore the end
<kazinsal>
enoX for onboards, ensX for hotplug slots, enpXsY for PCI addressed slots, ethX for anything more bizarre
<hgoel[m]>
there's also the very descriptively named re driver in freeBSD
<kazinsal>
so if you've got a machine with an onboard ge, a dual port ge in a PCI slot, and a 10 mbit ISA card in a PCI to ISA bridge, you've now got eno0, enp?s0, enp?s1, and eth0
<kazinsal>
where ? isn't guaranteed to be 0
<heat>
so that's how it works?
<heat>
TIL
<klange>
I took the PCI slot address approach.
<klange>
I like that because stuff doesn't just randomly get pulled out or reassigned on PCI slots.
<kazinsal>
yep, if someone's mucking around inside the machine, your hardware configuration is invalid and any interface config is going to need to be redone
<kazinsal>
you simply cannot assume that it'll just work
<kazinsal>
my approach is to do prefixX/Y, where X is the card number and Y is the port on the card
<kazinsal>
0 is the card number for the motherboard
<kazinsal>
prefix changes depending on what speed the card/port is, but changing the prefix doesn't change the card numbering
<kazinsal>
so eg. you can have ge0/0, ge0/1, ge0/2, ge0/3, ge1/0, te2/0, te2/1
<kazinsal>
and if the user fucks around inside the machine and those change, then that's because the user fucked around inside the machine.
<hgoel[m]>
I haven't decided on how I'll handle usb, but for pci I think I'll stick with scan order, matching known devices via hashing has various issues for usb
<hgoel[m]>
like if a usb ethernet controller was assigned and saved as eth0, removed and another added, which would either be assigned eth0 due to it being available (thus causing an issue if the previous one was plugged in at the same time)
<hgoel[m]>
I guess the labels could be exclusively owned by each device unless explicitly removed by the user, so the new one is given eth1 etc
ElectronApps has joined #osdev
andydude has joined #osdev
andydude has quit [Client Quit]
sts-q has quit [Ping timeout: 258 seconds]
<kingoffrance>
eh, none of these things are issues for me as a user. ethernet has mac addresses, at least on freebsd IIRC you can make any alias you want ep0 -> lan0 if you like. disks can use partition or filesystem labels. and on an old linux i see /dev/disk/ . im not sure what the issue is -- use indirect/meta names, no different than a symlink, which point to the "real" device name, and use that in configuration files/etc.
<kingoffrance>
if hardcoding stuff is a problem, "dont do that"
<kingoffrance>
hardcode an alias that the destination it points to can be changed
<kingoffrance>
wifi interface -> wifi0 use logical names, it is bad if an os doesn't provide that
<kingoffrance>
/dev/disk {by-id,by-label,by-partuuid,by-path,by-uuid) stuff just points to sda et. al. so you use the logical names in fstab and not hardcoded driver name
<kingoffrance>
there's perhaps more technicalities as to what stage of booting needs to be able to grok such and such, but as a user, these are solved IME
<kingoffrance>
other types of devices....may be another story....
X-Scale has joined #osdev
isaacwoods has quit [Quit: WeeChat 3.2]
<kingoffrance>
(for NICs, logical names means you dont have to update firewall configs or what daemons listen on, etc. if you change a device)
<kingoffrance>
only need to make sure the new device gets the proper alias
<kingoffrance>
also if you are doing interface bonding or something fancy, aliases give you a stable name despite what the underlying components might be (im not sure if that is proper term, different os might call it different things)
<geist>
tradtinoally linux assigned most things in the order it discovered (eth0, hd0, etc) but more recent distros seem to be renaming things in /dev (or whatever the interface stuff is) and/or setting up symlinks
<geist>
i remember for whatever reason that Solaris used to auto populate a fs called /device with long bus path names, and then create symlinks to them in /dev
<geist>
the interface renaming thing (enp6s0, etc) may be a systemd feature?
<geist>
iirc in dmesg you still see the kernel detect them as eth0 or whatnot, but then immediately they get renamed
<geist>
honestly dunno how you rename a nic on linux, since they traditionally dont end up with a /dev node? but then probably deep down they do
<klange>
iirc, one of the SIOC ioctls can assign a new interface name
<heat>
in linux nothing ends up with a /dev node unless either userspace mknod's it or you use their devfs thingy that more or less mounts a sane /dev made by the kernel
<kingoffrance>
yes, everything i say may or may not apply to modern systemd etc. i dont follow these things
<geist>
heat: sure, but tradtionally you didn't hae a /dev node for nics anyway, vs most other things
<geist>
ie, there was traditionally not a way to open a nic and just start reading from it like a file
<heat>
woah that's true
<heat>
TIL
<heat>
i had no idea
<heat>
never noticed network interfaces have no dev file
<geist>
so my point is that renaming it must be some other mechanism than just creating a different named file, since the name (vs most of the other things) seems to be more 'baked into' the kernel side of things
<geist>
though even in the old days it may have always been an ordinal somewhere for say ifconfig or other legacy utilities
<geist>
i guess the idea was there was no real point exposing a nic file since the business end of the nic driver terminates inside the kernel on the net stack
<geist>
and obviously you can get raw pipes to it, but it's via a different mechanism
<heat>
woah, ext4 extents are sooo cool
<geist>
klange: that SIOC ioctil you're talking about, what /dev or /sys file do you operate against?
<geist>
there's a million ways to skin it, just curious how it works if you looked at it recently
<heat>
my /var/log/pacman.log (package manager log file written since 2018) only has 169 extents, it's not even enough for a 2 tree levels!
<heat>
geist: it's on the socket
<geist>
heat: yeah filefrag is a super neat app
<klange>
geist: socket
<geist>
i use it all the time to look at fragmentation, etc
<heat>
I was using e4defrag -c -v
<geist>
yah check out filefrag. works on any fs that reports file layout info
<geist>
also interesting to watch things like btfs since you can more or less live watch COW work
pieguy128 has joined #osdev
<klange>
i'm shoving my interfaces in /dev/net for discoverability, `ifconfig` just readdirs over it to display everything
<geist>
yah that's what i did for newos back in the day
<kingoffrance>
there's stuff like /etc/networks and netgroups too, which i dont think many people use, doubly so nowadays, not arguing for or against either way, just more layers of aliases at other levels
<geist>
iirc that's how you opened a new socket too, etc
<geist>
something like /dev/net/socket and stuff like /dev/net/<network interface>
<heat>
i'm working on a netlink-like interface
<heat>
having to look at /dev is meh
<heat>
could work but then you're also limited, you'd need to add a bunch of device files for routing tables, etc
<klange>
toaru32 had /dev/net/{host}:{port} open TCP sockets, but I don't think I'll bring that back with the new stack
<klange>
and it mostly did that because all the DNS stuff was in the kernel module and there was no exposed method for doing UDP
<heat>
you could do it for IPs
<klange>
If I brought it back, I think I would try to implement Bash's magic network paths.
<klange>
Which I think is /dev/tcp/{host}/{port}
<heat>
yup, just tried
<heat>
super cool
<klange>
toaru32's /dev/net was basically that but in the kernel, so it worked anywhere
<Mutabah>
Heh, that's kinda how acess2's network interace worked too
heat_ has joined #osdev
heat has quit [Ping timeout: 252 seconds]
Oli_ has joined #osdev
heat_ is now known as heat
Oli_ is now known as Oli
srjek_ has quit [Ping timeout: 264 seconds]
<Oli>
test
<Oli>
Passed!
<Oli>
My bad.
heat has quit [Ping timeout: 265 seconds]
froggey has quit [Ping timeout: 240 seconds]
froggey has joined #osdev
sortie has joined #osdev
Burgundy has joined #osdev
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
dennis95 has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
GeDaMo has joined #osdev
Sos has joined #osdev
zoey has quit [Ping timeout: 268 seconds]
Tackwin has joined #osdev
ElectronApps has joined #osdev
gmacd has joined #osdev
dormito has quit [Ping timeout: 258 seconds]
gmacd has quit [Remote host closed the connection]
<sortie>
... whoops
<sortie>
My usleep(2) is off by (checks notes) 1000x
<froggey>
msleep or nsleep?
<sortie>
Miliseconds :)
<sortie>
So... it ran for a while
<sortie>
This happened in a pthread read/write lock test so I thought my implementation was wrong... nope it was the timer
<sortie>
I mean that's all their stuff, but they usually have a lot great security stuff now and then
<dzwdz>
openbsd has a very toxic community
<dzwdz>
and it builds on ideas which aren't that good in terms of security
<dzwdz>
unixes were made for trusted software and untrusted users, and pcs are the exact opposite of that
<gog>
the trusted computing platforms are trying to change that, but there's another bag of worms of vendor lock-in that gets opened with that
<gog>
open standards, closed ecosystem
<gog>
doesn't add up in my mind
<Bitweasil>
OpenBSD has a community of security people who have been, for the past couple decades, been reliably proven "Not paranoid enough."
<Bitweasil>
I'm surprised any of them still operate computers.
<Bitweasil>
I expect there's a regular flow of people out the back end who simply give up on computing entirely.
<dzwdz>
do y'all want to see a few notes about my idea for an secure os?
<Bitweasil>
I mean, you're welcome to discuss it.
<dzwdz>
they're garbage though
<Bitweasil>
Doesn't mean a thing without a well behaved processor under it.
<Bitweasil>
And most modern processors aren't.
<dzwdz>
well, yeah
<dzwdz>
but that doesn't mean that we should abandon security and run everything in ring0
<Bitweasil>
"Can I have this data I don't have permission to?" "No!" "But what if I speculate that the data has... a 1 bit here?" "oooh, talk speculation to me!... yeah, that's a 1..."
<Bitweasil>
Actually.
<Bitweasil>
It kind of does.
<gog>
and even if a microarch is provably correct, that's hard to do at scale
<Bitweasil>
The modern security model of a modern machine should assume any process can read the data out of any other process on the chip.
<Bitweasil>
Because that's what it's actually been for 15 years.
<dzwdz>
a malicious cpu isn't my only concern
Sos has quit [Ping timeout: 250 seconds]
<gog>
not even malicious, just fallible
<Bitweasil>
We've been running a cooperative multitasking OS and believing it's protected memory for a long, long time.
<Bitweasil>
Yeah, I don't believe Intel was actually malicious here.
<Bitweasil>
Just has built something so complex they can't understand it.
<sham1>
Running everything in Ring 0 is certainly an interesting idea. Maybe instead of relying on the processor for things like limiting memory access, you could do it based on the programming language, which could be done if the OS is actually a VM thing
<GeDaMo>
That's been done before
<Bitweasil>
We used to do that.
<sham1>
That's what some modern Lisp OSes do, yes
<Bitweasil>
Cooperative multitasking OSes are just a bunch of code politely staying out of the way of other people.
<dzwdz>
like, on most current systems a single malicious package maintainer could get root on a bunch of pcs at once
<Bitweasil>
MacOS was that way through... 7, possibly 9.
<dzwdz>
they're bad because i didn't mean to share them yet
<dzwdz>
but i'm curious what actual osdevs think about something like this
<dzwdz>
tldr: a microkernel-ish thing with a plan9 style vfs, but as opposed to p9 you can't regain access to directories that you were locked out of
Sos has joined #osdev
brcolow has quit [Ping timeout: 258 seconds]
heat has quit [Read error: Connection reset by peer]
andydude has quit [Quit: andydude]
vdamewood has joined #osdev
andydude has joined #osdev
tenshi has quit [Quit: WeeChat 3.2]
andydude has quit [Quit: andydude]
<klange>
graphitemaster: I've had weather on my panel for years :P
<klange>
Weather widget was added to the panel March 27th, 2017, was lost in the NIH update for a bit, but came back eventually alongside a JSON parser.
<graphitemaster>
John McAfee in the news, what crazy shit did he do this time, ... oh, ... oh
<gog>
yeah
<gog>
:|
GeDaMo has quit [Quit: Leaving.]
dormito has quit [Ping timeout: 264 seconds]
remexre has quit [Quit: WeeChat 3.0.1]
remexre has joined #osdev
dennis95_ has joined #osdev
dennis95 has quit [Quit: Leaving]
dennis95_ is now known as dennis95
andydude has joined #osdev
gog has quit [Quit: bye]
gog has joined #osdev
dormito has joined #osdev
gmacd has joined #osdev
mahmutov has quit [Ping timeout: 258 seconds]
amanita has quit [Ping timeout: 250 seconds]
srjek_ has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dennis95 has quit [Quit: Leaving]
sortie has quit [Quit: Leaving]
ahalaney has quit [Quit: Leaving]
nyah has joined #osdev
gmacd has quit [Remote host closed the connection]
<geist>
wow, for the first time since announcement, got an in stock alert for ryzen 5950x