channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=11&d=1
04:28:35 <geist> noodle meep moo
04:29:04 <klange> this is cute https://old.reddit.com/r/osdev/comments/9t4dwh/introducing_desk64_a_new_64bit_smp_unixlike/
04:29:14 <klange> has a very interesting pre-ansi C compiler
04:29:29 <geist> yah retro unix clones is all the rage now
04:29:34 <klange> which is... an amusing [intentional] design decision
04:29:38 <geist> i've even considered it a few times
09:42:02 <aalm> .ken
09:42:02 <glenda> My experience and some of my friends' experience is that Linux is quite unreliable.
09:42:12 <aalm> .roa
09:42:12 <glenda> 112 Never have sex with the boss's sister.
09:42:18 <aalm> .theo
09:42:18 <glenda> So the original idea wasn't yours. And now you think it can't work. And you are still talking about it. I see. Very interesting.
09:42:35 <izabera> have sex with your sister's boss
09:48:47 <aalm> tbh., i don't want/accept anyones sister anymore, wasted some years w/my "best friend"'s sister already:p
10:09:03 <izabera> i'm someone's sister
10:09:40 <izabera> my sister is also someone's sister
10:10:12 <FireFly> your sister's sister is also someone's sister
10:10:31 <izabera> tru
10:29:58 <aalm> i haz sisters too, but they're irrelevant:]
10:30:04 <aalm> .roa
10:30:04 <glenda> 23 Nothing is more important than your health ... except for your money.
10:30:35 <aalm> mischief++, i liek .roa; well done
10:31:31 <mischief> thank star trek
10:31:39 <mischief> and sl of 9front.
10:36:48 <aalm> oh, i thought your boss had an sister, idk. where i got that you would have written those yourself ;P
10:37:37 <mischief> these are the ferengi rules of acquisition
10:37:45 <mischief> not sure what you thought it was.
10:49:53 <aalm> idk.
10:49:58 <aalm> do you like csh?
10:50:24 <aalm> was just closing tabs and came across this: https://github.com/weiss/original-bsd/commit/016cb802aeb433bbefdf2c9913a32990bb96befc#diff-e50d85e93bc52a13982725d1316805a4
10:54:33 <aalm> despite the age of that commit(+30years), atleast "kre" is still hacking on (Net)BSD :o
11:42:30 <dormito> do scheduling algos for O(1) in both reschedule AND sleep/wake exist? (I'm not sure you can do sleep/wake in O(1)....)
11:42:59 <bauen1> also, `typedef void documentation;`
12:26:44 <mrvn> dormito: that's trivial. A simple round-robin scheduler with circular lists for sleeping and awake processes is O(1)
12:52:36 <mrvn> I'm still not convinced one even needs anything more complex than round-robin with preemption.
01:05:49 <dormito> mrvn: it's not O(1) for sleep &| wake
01:07:12 <klange> is it?
01:08:08 <klange> assuming you already have a handle to the task, removing from an arbitrary place in the circular list is O(1) assuming it has a reference to its container, as is inserting into the ready queue where you have a reference to insert into the end...
01:09:14 <dormito> ok but how do you know when to put it back on the run queue?
01:09:52 <bauen1> dormito: if it was preempted, put it back on the ready queue and schedule the next task
01:10:02 <dormito> ...
01:10:14 <bauen1> ?
01:10:14 <dormito> how do you know when to put a sleeping taks on the run queue
01:10:39 <klange> define "sleeping"
01:10:50 <bauen1> dormito: https://wiki.osdev.org/Blocking_Process
01:10:57 <bauen1> unless you want a O(1) sleep function
01:11:12 <bauen1> which might not be possible
01:11:12 <dormito> that's what I asked about
01:13:02 <bcos_> dormito: The best I've seen for "sleep" is to have a series of buckets where something like "(wake_time / bucket_duration) % number_of_buckets)" determines which bucket a sleeping task is put into; which can be "O(1)" if the bucket_duration is equal to time between ticks
01:13:03 <dormito> and yes. I do not *think* you can have both an O(1) scheduler and an O(1) sleeep/wake (or sleep function if you prefer). but I am not totally sure about that (hence why I asked)
01:13:18 <bcos_> ..and if there's enough buckets of course
01:13:37 <bauen1> dormito: if you have an ordered list where the insert is O(1) it's possible to have both
01:14:00 <dormito> how can you insert into an ordered list in O(1)?
01:14:27 <bauen1> i don't think you can
01:14:47 <dormito> lol.
01:15:02 <Vercas> dormito: You can use more than one list instead.
01:15:11 <Vercas> Or have a list with multiple heads/tails.
01:16:47 <Vercas> Either way this will be O(1) unless the number of lists/heads&tails can grow at runtime. :P
01:17:23 <mrvn> Oh, by sleep you mean actually sleep(x) syscalls.
01:19:05 <dormito> it need to be a syscall. just processes/thread yieilds for at least X time units (which is what the syscall does... but it makes sense for kernel threads to do that as well)
01:19:14 <dormito> *it need not be a syscall
01:19:19 <klange> the scheduler can still be O(1) as it can do O(1) lookup of timed stuff, but insertion into the scheduling queue ... insertion into a sorted list, no.
01:19:48 <mrvn> sleep(x) is O(log n) per process but that would be the cost of calling sleep(x). Not cost of the scheduler itself.
01:19:50 <Vercas> Hm, I would honestly keep the wake up and scheduling shenanigans separate.
01:20:06 <Vercas> I would let my timer system take care of waking up threads.
01:20:15 <bauen1> well, you could just have the task busy loop in the sleep syscall which would make both O(1) ...
01:20:52 <mrvn> bauen1: That would be O(n) since you would have to run through all sleeping processes every loop of your sechduler.
01:21:26 <bauen1> true
01:21:29 <dormito> Vercas: obviously you need timers involded, but you also need the schuler involed some what. I mean it has to know to remove from the queue (if applicable), and then add back into the queue (or the rough analogise of those ops)
01:21:38 <klange> for timed sleeps, I keep a sorted list...
01:22:04 <Vercas> dormito: That really should be O(1) unless you done goof'd.
01:22:04 <mrvn> dormito: if you have a sorted list of processes waiting on a timer then the scheduler only needs to check the head of the list.
01:22:11 <dormito> klange: that's what I've started on. with an int for the soonest one
01:22:44 <dormito> Vercas: if you can point me at a algo to insert into a sorted list in O(1) let me know
01:22:51 <mrvn> dormito: there isn't.
01:22:56 <Vercas> You don't need to insert into a sorted list.
01:23:05 <Vercas> You need to pop the head off a sorted list.
01:23:09 <dormito> ...
01:23:23 <dormito> yes thats for waking
01:23:25 <Vercas> If the head of the sorted list mustn't be the *next* thread to run, don't pop it.
01:23:41 <dormito> but if you wanna put the processes to sleep.... you must insert into a sorted list
01:23:51 <mrvn> dormito: switching tasks and waking is O(1). Putting a process to sleep is O(log n).
01:24:05 <Vercas> ^
01:24:06 <dormito> mrvn: I'm not diagreeing
01:24:07 <klange> what you do at the time of the sleep call isn't /technically/ relevant to the "runtime performance of the schedular"
01:24:12 <klange> plus you're sleeping, who cares :)
01:24:53 <Vercas> O(log N) is an incredibly good asymptotic complexity class for inserting into lists.
01:25:34 <mrvn> dormito: There are two kinds of sleep though: usleep(1) and sleep(500). The later is rare and nobody cares what you do there much. But realy short sleeps should be fast. A good optimization is to have buckets for short sleeps and something sorted for long ones.
01:25:36 <Vercas> Keep in mind that, if your list contains a million items, that means 20 operations.
01:26:08 <mrvn> Vercas: can't be a list for that though. At least a skip list would be needed.
01:26:22 <Vercas> A simple linked list - indeed not.
01:26:34 <Vercas> But a contigious array or skip list - hell yeah.
01:26:36 <Vercas> Or a tree.
01:26:48 <mrvn> array would be bad too. insert would have to shift all entries
01:26:55 <Vercas> Oh, good point.
01:27:08 <Vercas> AVL or R/B tree would work.
01:27:16 <Vercas> The node structure can be embedded in the thread structure.
01:27:53 <mrvn> I myself like buckets. A few buckets 10,20,30,40...us sleeps and then one each for <10ms, <100ms, <1s, <10s or so.
01:28:30 <Vercas> How would you do microsecond-precision sleeping on x86, though?
01:28:57 <mrvn> Vercas: the high precision timers
01:29:49 <bcos_> dormito: Imagine you have a timer IRQ that occurs every 1 ms, and 100 lists (used in a rotating way) to keep track of what to wake up in the next 100 ms (where timer IRQ just wakes up everthing in the "most recent" list). That's O(1) but limited to 100 ms of time. Now imagine you have another 100 lists to keep track of what to wake up in the next 10000 ms, where every 100 ms you shove everything in the "most recent" 100 ms list into the "1 ms lists". It's
01:29:51 <bcos_> still O(1) but now its limited to 10000 ms. Now add 5 more layers of this to bring it up to "O(1), limited to 100000000000 seconds".
01:30:37 <Vercas> mrvn: I mean - would you schedule another thread for a 10-microsecond sleep or would you loop instead?
01:30:50 <mrvn> bcos_: on the other hand it is O(log n) for each sleeping process.
01:30:54 <Vercas> Also, do you mean the HPET or basically anything except the PIT?
01:31:10 <mrvn> Vercas: if you have a thread then run it. When idle then loop.
01:31:18 <bcos_> mrvn: How? With 7 layers it'd be "O(7)"
01:31:19 <Vercas> I see.
01:31:19 <mrvn> Vercas: both
01:31:51 <mrvn> bcos_: where 7 is log(maximum number you can sleep)
01:32:50 <bcos_> I think 100000000000 seconds is about 3000 years, so..
01:33:14 <mrvn> bcos_: sure. That's the practical side. but theoretically you have to consider infinite sleeps.
01:34:05 <mrvn> bcos_: also sorting the 10000ms list is an O(n) operation.
01:34:09 <bcos_> That's easy -if anyone wants to sleep for longer, just terminate the thread instead. The OS will reboot before anyone realises a sleeping thread should be woken up ;-)
01:34:47 <mrvn> bcos_: I think that comes out as amortized O(log n) scheduler.
01:35:03 <bcos_> Maybe
01:35:23 <bcos_> In practice; the killer is timer events being cancelled.
01:35:54 <mrvn> bcos_: That's the beauty of the design. cancel is O(1) and saves time.
01:36:15 <Vercas> Also, one thread requesting that another be woken.
01:36:35 <mrvn> the buckets delay the cost of sleep(x) as much as possible so cancel saves the time not yet spend.,
01:36:36 <Vercas> Injecting signals is one use case.
01:39:14 <mrvn> Vercas: use doubly linked lists. Then waking up a task means you remove it from the list and insert it into another. so task->prev->next = task->next; task->next->prev = task->prev; ...
01:39:58 <Vercas> Aye.
01:43:23 <bcos_> I don't think you can do "block-free" for doubly linked lists (you'd end up with "O(number_of_CPUs)" due to lock-free or locks)
01:43:42 <bcos_> Rather than removing a cancelled event from a list; you can (atomically) set a "discard later" flag; and just use singly linked lists
01:50:22 <klange> ふーん https://www.sigbus.info/compilerbook/
01:52:19 <mrvn> bcos_: you can cascade timer interrupts from cpu to cpu so they never ever schedule at the same time. :)
01:55:33 <mrvn> and then to take the lock on the list you only have to wait for one cpu to finish scheduling and can do the cancel in the time before the next one starts.
01:56:35 <mrvn> or you have per-cpu timer lists. Downside there is that waking up means telling another core to wake up the task or locks again.
01:58:19 * bcos_ would be tempted to use "global" for long-term buckets and "per-CPU" for short term buckets; partly because there's annoyances with local APIC in some sleep modes that can cause everything to need to be shifted to HPET
01:58:50 <mrvn> bcos_: and for a short sleep you probably don't want to move the task to another cpu anyway.
01:59:36 <mrvn> as in: have per cpu lists of running processes too
02:00:03 <bcos_> If the short sleep buckets aren't empty, you know the CPU will need to wake up soon and know the CPU shouldn't be put into lower power sleep mode
02:00:27 <bcos_> Hrm
02:00:35 <mrvn> and if it is empty you can do some work stealing from other cpus even if that is costly.
02:01:40 * bcos_ was reading something about "doing nothing" in Linux the other day, thinking that it's a bit simplistic because it doesn't look at "when next task wakes" to figure out which power saving state to put an idle CPU in
02:06:17 <bcos_> ( https://lwn.net/Articles/767630/ )
02:06:24 <mrvn> One of these days, in the far far future, I will have to look into power management on ARM for my kernel.
02:23:18 <zenix_2k2> guys by not using lsblk, parted... how can i really tell the size of all of the partitions on my machine ? also let's just say their devices file are sda, sda1, sda2 and sda3
02:23:33 <zenix_2k2> sda is supposed to represent the disk and the others, partitions
02:26:20 <klange> these are seriously linux-specific questions and not things that you should keep coming in here to ask
02:33:51 <zenix_2k2> idk, some people usually point me to this channel for these kinda stuffs
02:33:54 <zenix_2k2> so yea sorry :P
03:25:22 <lkurusa> zenix_2k2: it depends on how you phrase it
03:25:34 <lkurusa> i.e., 'how would a kernel expose this information to its userspace'
03:25:46 <lkurusa> now *that* is relevant to osdev
03:26:21 <lkurusa> the answer really is, if you are writing a UNIX-like, then its probably either procfs, or some ioctl's
03:26:44 <lkurusa> at that point, you can go and look through the source code of lsblk for ioctl calls maybe
03:26:55 <lkurusa> or open()s of /proc files
03:27:02 <lkurusa> strace might prove handy
03:30:56 <zenix_2k2> ok thank
04:44:19 <mra90> What books is recommended for writing windows drivers (Win 7-10)
04:51:25 <bcos_> mra90: This channel is mostly people writing their own OS (not people writing software for existing OSs like Windows)
04:52:47 <mra90> bcos_: but most of us play with big OSes already available, don't we?
04:53:44 <lkurusa> yeah, linux
04:53:57 <lkurusa> there's a windows internals book btw
04:55:52 <mra90> lkurusa: +1 for windows internals
04:57:02 <bcos_> I assumed the "Windows device driver developer kit" included whatever documentation makes sense
04:58:17 <mra90> what about linux?
04:58:55 <lkurusa> there's literally a book called 'linux device drivers'
04:58:55 <clever> mra90: i like https://bootlin.com/doc/books/ldd3.pdf
05:00:28 <bcos_> Hrm - 2005
05:00:42 <clever> there is a 4th edition to the book as well
05:01:04 <clever> https://www.reddit.com/r/linux/comments/61q6y8/what_happened_to_linux_device_drivers_4th_edition/
05:01:36 <clever> ah nvm, no 4th one
05:02:25 <mra90> 3rd one from 2005 seems to be the newest
05:15:49 <Vercas> mrvn: Uhm, what?
05:16:02 <Vercas> Oh.
05:16:05 <Vercas> I geddit now.
05:17:08 <Vercas> mra90: What type of Windows drivers do you wanna develop?
05:17:20 <Vercas> Also sorry mrvn for the wrong highlight. :C
05:18:12 <Vercas> mra90: Because I can tell you that Windows Internals won't do you any good for most serious driver development. You need OSR's help for that.
05:19:03 <mra90> Vercas: drivers for usb as well as dsp chips on motherboard
05:19:25 <Vercas> For USB devices? That should be the easiest.
05:23:32 <mra90> What about dsp?
05:23:51 <mra90> which has IPC
05:24:12 <mra90> and heavily relys on it
05:30:52 * geist yawns
05:37:15 * lkurusa yawns
05:37:18 <lkurusa> yawning is viral
05:40:58 <glauxosdever> Indeed.
05:45:26 * geist cackles evilly
05:45:47 <glauxosdever> Shame on you, geist
07:31:09 <blackandblue> hi geist, may I know why you use linux mint over ubuntu? asking out of curiosity
07:36:05 <abysslurker> o/
07:47:22 <geist> i like mate
07:47:30 <geist> though i have generally started switching to cinnamon
07:48:07 <blackandblue> geist, you on mint 19 cinnamon?
07:48:08 <geist> nowadays there is less of a distinction, since you can use mate/cinnamon on ubuntu
07:48:29 <glauxosdever> I also use MATE (but with Debian)
07:48:33 <geist> generally yes, thats what i do if it's a desktop that i'm going to interact with
07:48:40 <geist> if it's a server i just put stock ubuntu on
07:48:57 <geist> i'm also using cinnamon at work
07:49:01 <blackandblue> where do you do most of your work (OS development)
07:49:05 <blackandblue> in mint or ubuntu?
07:49:12 <glauxosdever> Ubuntu isn't heavier though?
07:49:21 <geist> both
07:49:24 <geist> and mac
07:49:27 <abysslurker> I like GNOME
07:49:42 <glauxosdever> GNOME 3?
07:49:46 <geist> frankly it doesn't matter much to me. but i generally use something downstream of ubuntu
07:49:53 <geist> vs say gentoo or arch or redhat
07:49:56 <abysslurker> Stock ubuntu has a really nice desktop environment nowadays
07:50:22 <geist> work linux is debian based, but has a cinnamon ui
07:50:34 <abysslurker> glauxosdever: yeah, GNOME 3. I know some people hate it with a passion, but I think it's fine and easy to use.
07:50:42 <blackandblue> ah mac. macOS blows mint out of water
07:50:42 <blackandblue> :(
07:51:35 <geist> in general i just use gvim and stock posixy bits and chrome, so it doesn't matter too much to me as long as window management is fine
07:51:47 <geist> i even have an arm ubuntu box here that runs all that fine too
07:51:53 <kryptonunited> your preferred window management is cinnamon?
07:51:58 <geist> yes
07:52:20 <glauxosdever> I tend to be a bit more old-school (I don't like touchscreen-like icons)
07:52:36 <geist> same. i usually use some sort of clearlooks looking thing
07:52:37 <kryptonunited> you use gLinux at work? geist
07:52:40 <geist> yes
07:52:53 <kryptonunited> how is it as compared to linux mint cinnamon
07:52:57 <kryptonunited> better or worse?
07:53:00 <abysslurker> glauxosdever: touchscreen-like icons?
07:53:18 <glauxosdever> Those big ones.. like in Unity
07:53:33 <geist> pretty much the same. using cinnamon it looks and acts more or less the same way
07:53:52 <kryptonunited> and how about stability differences?
07:54:09 <geist> stable to me. i haven't rebooted this box in a month or so
07:54:19 <kryptonunited> gLinux or mint?
07:54:19 <abysslurker> glauxosdever: other than the top search results I can't think of any icons that are large enough for a touchscreen in GNOME 3
07:54:24 <geist> both
07:54:37 <kryptonunited> geist, I see. so no difference b/w them basically
07:54:39 <geist> stability isn't a thing that i concern with too much
07:54:57 <geist> that being said, pretty much all my machines are nvidia based, except for one AMD built in gpu at home
07:55:06 <geist> and i do use nvidia's drivers
07:55:11 <glauxosdever> The taskbar icons are also too big for my liking (judging from screenshots I saw)
07:55:11 <geist> and they've been nice and stable for me
07:55:31 <geist> vs the last time i tried to use an AMD radeon driver for linux, which was a crashy mess
07:55:49 <kryptonunited> geist, can you please show me your desktop screenshot?
07:55:53 <geist> no
07:56:06 <kryptonunited> it looks default or customized?
07:56:09 <glauxosdever> geist: So that's a "So, AMD, **** you" moment? :p
07:56:14 <geist> a) i'm not in front of my personal desktop right now and b) i can't screenshot the work one for security reasons
07:56:22 <kryptonunited> oh ok
07:56:30 <kryptonunited> I thought you are on your personal desktop
07:56:37 <geist> no, i'm at work right now
07:56:56 <kryptonunited> you use macOS along with linux at work?
07:56:59 <kryptonunited> side by side?
07:57:01 <geist> sometimes
07:57:13 <abysslurker> glauxosdever: they are smaller in Ubuntu's version of GNOME 3. Anyhow, I'm pretty sure that kind of stuff is customizable.
07:57:41 <geist> http://tkgeisel.com/pics/desktop.png is some older one from a few years ago. that's using mate i think
07:58:04 <geist> but usually that's about all i want. something that gets out of my way, and a toolbar along the bottom or top with a list of windows
07:58:09 <geist> and a way to switch desktops
07:58:21 <kryptonunited> I see.
07:58:26 <kryptonunited> cinnamon doesn't crash on you ?
07:58:30 <geist> negative
07:58:30 <glauxosdever> geist: That's a very high resolution!
07:58:37 <abysslurker> geist: is Zircon multiple years old already?
07:58:41 <geist> yes
07:58:42 <kryptonunited> geist, cool!
07:58:59 <kryptonunited> geist, how do you handle HiDPi in cinnamon
07:59:03 <geist> i dont
07:59:12 <geist> none of my machines have hidpi monitors
07:59:26 <isaacwoods> geist: how long has fuchsia been in the works, or is that not up for discussion?
07:59:39 <geist> isaacwoods: since early 2016
07:59:49 <glauxosdever> So.. almost 3 years
08:00:01 <geist> yes, that is how math works
08:00:06 <glauxosdever> :p
08:00:34 <glauxosdever> I mean, what have you implemented during these 3 years?
08:00:41 <geist> a bunch of stuff
08:00:52 <geist> as in fuchsia didn't exist prior to that, so therefore everything there is in the last 3 years
08:01:16 <geist> with the exception of pieces of open source that came in, or existing projects like flutter that got pulled in
08:01:28 <geist> in the case of zircon it started off as a fork of LK
08:01:28 <abysslurker> and how many years is it until I can replace my Linux install with Fuchsia?
08:01:57 <geist> so it wasn't entirely from scratch, though most of LK is mostly replaced
08:02:12 <glauxosdever> Would you say you are developing it fast or slow?
08:02:21 <geist> it's kind of like a little boat that we added more boat to and eventually the original hull is mostly replaced, or is now just an internal pressure vessel
08:02:57 <abysslurker> geist: so LK in Zircon is Theseus' ship at this point?
08:03:03 <geist> yah
08:03:05 <geist> bbiab. lunch
08:03:47 <kryptonunited> abysslurker, what linux distro are you rocking ?
08:04:15 <abysslurker> Ubuntu, I've never put much thought in my choice though.
08:04:48 <kryptonunited> abysslurker, in VM / dual boot?
08:05:26 <abysslurker> I think I have a Windows 10 install on this laptop, but I haven't booted it in a year or so.
08:08:36 <kryptonunited> abysslurker, on 16.04 Unity?
08:08:56 <abysslurker> 18.04, gnome
08:09:07 <abysslurker> ran 16.04 gnome before that
08:09:19 <kryptonunited> upgraded or fresh installed?
08:09:39 <kryptonunited> since upgrades are not so smooth fwih
08:09:54 <abysslurker> i always do a fresh install, upgrades with ubuntu always break on me
08:10:08 <kryptonunited> yea
08:10:11 <kryptonunited> thats pretty sad
08:14:18 <abysslurker> oh well, it's 10 minutes every 2 years, I can live with that
10:23:40 <lkurusa> https://www.openwall.com/lists/oss-security/2018/11/01/4
11:15:44 <dormito> blah. moving to a saner scheduler has found another bug: sleeping in before interrupts are enabled :/ (not by design, but in that case, it would effectively spin untill the specified time elapsed)