kerio has quit [Write error: Connection reset by peer]
kerio has joined #neo900
ecloud_wfh is now known as ecloud
dal2 has quit [Quit: Leaving.]
mvaenskae has joined #neo900
modem has joined #neo900
paulk-collins has joined #neo900
vakkov has quit [Ping timeout: 246 seconds]
mvaenskae has quit [Ping timeout: 252 seconds]
sparetire_ has quit [Quit: sparetire_]
vakkov has joined #neo900
vakkov has quit [Ping timeout: 252 seconds]
vakkov has joined #neo900
che1 has joined #neo900
che1 has quit [Ping timeout: 245 seconds]
che11 has joined #neo900
vakkov has quit [Ping timeout: 246 seconds]
freemangordon has quit [Read error: No route to host]
mvaenskae has joined #neo900
freemangordon has joined #neo900
vakkov has joined #neo900
ddark has joined #neo900
mvaenskae has quit [Ping timeout: 256 seconds]
vakkov has quit [Ping timeout: 264 seconds]
vakkov has joined #neo900
paulk-collins has quit [Remote host closed the connection]
P-G has joined #neo900
vakkov has quit [Ping timeout: 245 seconds]
vakkov has joined #neo900
vakkov has quit [Ping timeout: 256 seconds]
mvaenskae has joined #neo900
<DocScrutinizer05>
I wonder what's blocking community / "hired" effort to get a spacerframe prototype made already
<DocScrutinizer05>
wpwrak: for the new shape and component placements we simply reference the new to old shape, since we know where the old one been defined for position ("kamelhoecker", the three points I mentioned)
<DocScrutinizer05>
oops ECHAN
SylvieLorxu has joined #neo900
paulk-collins has joined #neo900
vakkov has joined #neo900
Pali has joined #neo900
vakkov has quit [Ping timeout: 264 seconds]
<DocScrutinizer05>
dolibarr expert anybody? help wanted
<DocScrutinizer05>
kerio: >>.cm is the country code top-level domain (ccTLD) for Cameroon.<< ??? :-o
<kerio>
that's pretty fucking random
<kerio>
do you have away notifications turned on? :O
<DocScrutinizer05>
[2015-03-20 Fri 08:21:29] <-- kerio (~kerio@duckbot.xd.cm) has left this server (Write error: Connection reset by peer).
<kerio>
WUT
<kerio>
i don't remember that
<kerio>
no maybe i do
<kerio>
hmmmmmm
<kerio>
i thought znc restart quit the connections
<kerio>
rather than dropping them
<DocScrutinizer05>
no it won't
<kerio>
openssl update
<DocScrutinizer05>
:-)
<kerio>
i should really move to libressl
<kerio>
the "high" bug was caused by a downgrade onto rsa export ciphers
<kerio>
they simply don't exist in libressl
<DocScrutinizer05>
wait, there's yet another ssl secpatch?
<kerio>
the last one
che11 has quit [Ping timeout: 272 seconds]
<kerio>
the 19 march one
<DocScrutinizer05>
*sigh*
<kerio>
debian stable is on 0.9.8zf
* DocScrutinizer05
heads to his boxes, doing updates
<kerio>
due to the incorrect SOC calculation the phone won't try to charge the battery more because it doesn't want to damage it
<kerio>
that's idiotic
<kerio>
you use *voltage*
<P-G>
"As you use your device you're drawing current out of the battery and the battery's voltage will drop - eventually. By measuring the current and monitoring the voltage you can guess what the SOC is. One problem is that the voltage isn't terribly useful in determining SOC because it doesn't change very much until the battery is nearly empty - that is NOT something you want to do to a Li-On
<P-G>
battery. So you're mainly relying on the current."
<P-G>
This is all witchcraft to me but there are clearly different implementations across the phone and laptop markets.
<kerio>
the first answer seems dead wrong to me
<P-G>
Yeah, I don't know. Most netbook and tablet implementations on the market seem dead wrong to me. :p
<DocScrutinizer05>
kerio: ((you use *voltage*)) no, current actually, when charge near completion
<P-G>
Speaking of laptop markets...
<DocScrutinizer05>
P-G: that quote is one large pile of BS
<DocScrutinizer05>
complete disinformation
<DocScrutinizer05>
misinfo
<DocScrutinizer05>
LiIon charge end detection is _only_ via voltage, nothing else
<P-G>
Well, I konw Lithium Ion batteries can provide regulated current throughout discharge. I don't know whether that's actually a product of the batter or some external circuitry manufacturors build into their products though.
<DocScrutinizer05>
LiIon charge end detection is via charge current dropping under a certain threshold while keeping voltage at a constant 4.1V per cell
<DocScrutinizer05>
nothing provides "reglated current" in a LiIon (or any other) battery
<P-G>
Hm.
<DocScrutinizer05>
current are Ampere and are determined by what the connected consumer "asks for"
<P-G>
I guess that's specific battery packs. You're right.
<P-G>
But output would generally be regulated somewhere and battery charge would be calculated after that?
<DocScrutinizer05>
a LiIon cell provide 4.2 down to 3.5V during discharge, at a current ideally and typically sufficiently high to power your circuit
<DocScrutinizer05>
no
<P-G>
So there a method of testing charge built into the battery itself and that reports to the charging circuit?
<DocScrutinizer05>
usually no
<DocScrutinizer05>
most simple way to guess remaining capacity is from voltage: 4.1V = 100% 3.6V=0%
<P-G>
Would that method need to be recalibrated periodically?
<DocScrutinizer05>
there are smarter ways, like e.g. BQ27200 battery gas gauge as used in N900 and OpenMoko freerunner which actually meters the total of electrons in and out of battery
<P-G>
That's possible??
<DocScrutinizer05>
sure
<P-G>
Jeeze.
<DocScrutinizer05>
not on single electron resolutio/precision, but still
<P-G>
That science is like a thousand metres over my head.
<P-G>
Oh, ok. Phew.
<P-G>
That really scared me...
<DocScrutinizer05>
that's (milli)Ampere*hours then, shirt: mAh
<DocScrutinizer05>
short*
<DocScrutinizer05>
and you can compare the metered mAh value to e.g last measured full, or design, capacity of cell and express the charge level as PERCENT
<DocScrutinizer05>
downside of this method: it needs a defned starting point. I.E. the counter getting reset when battery charging completes
<P-G>
So that would be accurate to 0.01%?
<DocScrutinizer05>
until then the meter is not in sync with the cell's status
<P-G>
Then you recalibrate by deep discharge?
<DocScrutinizer05>
well, accuracy in battery capacity is a whole topic of it's own
<DocScrutinizer05>
yes
<DocScrutinizer05>
that's *exactly* what you do to calibrate "last measured discharge" in bq27200
<P-G>
And that doesn't kill it by discharging too deep because of seperate protection circuit?
<DocScrutinizer05>
alas capacity of a cell is not really a simple fixed value, it depends on a few factors like the load you connect (strong load will reduce effective total capacity) and temperature etc
<DocScrutinizer05>
no, the process itself stops discharging when battery reached nominal dicharge end voltage of ~3.55V
<DocScrutinizer05>
the protection circuit is there to help when this doesn't work for whatever reason
<P-G>
So the first layer of protection is in the battery and the second is in the charging circuit.
<P-G>
Would that run on Neo900 or would it need to be modified? Maybe it's just not necessary.
<DocScrutinizer05>
it should run unchanged on Neo900 when you use maemo as OS
<DocScrutinizer05>
well, no
<DocScrutinizer05>
sorry
<DocScrutinizer05>
while Neo900 has same bq27200 chip, it's using a slightly different (way smarter) charger chip which doesn't even need stuff like BME, so you would either need to alter the script or simply unplug and replug the USB charger manually according to the messages from script
<P-G>
Would the script be an improvement or is the new chip better?
<DocScrutinizer05>
it's using a slightly different (way smarter) charger chip which doesn't even need stuff like BME
<P-G>
Think I should try to find an N900 or hold out for Neo900?
nox- has joined #neo900
<P-G>
The phone I have now is annoying but it does work fine.
<DocScrutinizer05>
N900 is a great device. Prolly as good as it gets until Neo900 becomes available. At least when a Neo900 is what you'd want to use finally
fling has quit [Ping timeout: 264 seconds]
<kerio>
alright
<kerio>
my dad now has a chinese androidphone
<kerio>
100 eurobucks
<kerio>
and i have to admit it, it looks cool
<kerio>
and then i started using it a bit
<kerio>
holy shit how do people stand android
<sixwheeledbeast>
they feel there's no other options
<DocScrutinizer05>
hmm, somewhat known resp expected. Even more concerning though: seems RedHat for example might want to get such cert from M$ to sign their own systemd-based linux and lock it down to a degree where it's up to RH what to allow on their linux and what won't run
<DocScrutinizer05>
Nokia shown the way in HARM and aegis
<P-G>
That idea seems good in principle, right? Requiring safe execution is a good thing.
<P-G>
Like SE Linux but for memory?
<DocScrutinizer05>
the principle is flawed in my book. A decent system doesn't allow any of those attack vectors that TrustedComputing *pretends* to defeat for user
<DocScrutinizer05>
apps messing with system boot? WHAT?? on my systems only root is allowed to mess with boot
che11 has quit [Remote host closed the connection]
<P-G>
Wouldn't it be useful to isolate memory allocation by PID or something like that?
<P-G>
Each program thinks it's accessing normal memory pool but it's virtual. Programs communicate by shared pools which are specific to the programs that are supposed to be sharing it.
<DocScrutinizer05>
err what? that seems a standard in all contemporary OS since at least 10 years
<P-G>
I hope it is, lol. I don't actually know. :p
<DocScrutinizer05>
rather since 30
<P-G>
I hear about programs accessing memory allocated to other prigrams.
<DocScrutinizer05>
there's no known attack vector like that in linux
<DocScrutinizer05>
any such vulnerability gets fixed within days
<kerio>
lolwut
<kerio>
why do people get these weird ideas
<P-G>
Huh. Ok, I guess it's all good then. Trusted computing wouldn't add anything.
<kerio>
do you really think that your computer is like a gameboy
<P-G>
I have no idea how O.S. are programmed.
<DocScrutinizer05>
of course you can add a second layer of protection - like SElinux - to catch the occasional zero day exploit in kernel
<P-G>
SE Linux affects user access permissions, right? Does it change processor/memory allocation?
<DocScrutinizer05>
*none* of all that is new, or would need that TrustedComputing stuff
<ShadowJK>
Actually, via firewire you could access entire memory.. but this might be fixed now atleast on AMD's AMD64 arch, where the CPU can be (ab)used as IOMMU also
<DocScrutinizer05>
generally when any app can tamper with boot process, then your OS *is* already pwned and the rogue app could already do whatever rogue stuff it likes. And no TC will help you then
<DocScrutinizer05>
TC is *only* to protect the device form user
<DocScrutinizer05>
from*
<DocScrutinizer05>
and to establish total control by manudacturer over what _you_ may or ,ay not do on _your_ device
<P-G>
I don't like it either, I just thought it did something with the memory. It may well not.
<P-G>
Maybe I read the news too much but I read about a lot of memory exploits.
<P-G>
No idea how they actually work.
<DocScrutinizer05>
generally when any app can tamper with boot process (e.g. by exploiting a vulberability in memory management), then your OS *is* already pwned and the rogue app could already do whatever rogue stuff it likes. And no TC will help you then
<P-G>
So what manages the memory in linux? I need to do some homework.
<DocScrutinizer05>
TC will only block your attempts to boot the OS of your choice, and enforce a OS (kernel) that decides what you may or may not do
<DocScrutinizer05>
>>So what manages the memory in linux?<< I think the question is already not what you actually want to ask
<P-G>
How does linux manage memory allocation?
<DocScrutinizer05>
to answer it nevertheless as good as possible: the kernel handles memory in linux, usually by means of memory allocation tables
<P-G>
Ok, so it is in there after all...
<P-G>
Kernel is C?
<P-G>
And assembly?
<DocScrutinizer05>
please google for "operatin system (linux)"
<P-G>
Yes, Wikipedia says C and assembly.
<ShadowJK>
P-G, basically, since the 386 processor and onwards, hardware memory protection has been available to operating systems.
<DocScrutinizer05>
these are basic questions that are years of learning away from how UEFI boot works and what's a memory management based exploit
ddark has quit [Ping timeout: 272 seconds]
<P-G>
You can't learn about exploits if you don't understand what is being exploited.
<DocScrutinizer05>
exactly
<P-G>
If it's that old and it's still in use, that's all the more reason I should look into it.
<DocScrutinizer05>
thus: please google for "operating system (linux)"
<DocScrutinizer05>
as I said, it's years of learning from "what's a MMU" to "how does TC work"
<ShadowJK>
P-G, every process that runs under Linux, has its own memory space, and by that I mean that every process can have memory address "9000", or whatever, the kernel tells the hardware that process X, address 9000, is address Y in physical ram. If Process X tries to access an address that isn't assigned to it, the CPU stops the process and returns control to the kernel. The kernel may then decide what the correct action is.
<P-G>
Well, I think I understand the idea of TC. I don't have any idea how it works programmatically of course but I don't really care about that.
<DocScrutinizer05>
usually the notorious SIGSEGV aka segfault
<ShadowJK>
It could be that
<P-G>
Ok, that makes sense. And when programs need to communicate, a new memory segment is allocated to both processes?
<P-G>
Processes, not programs.
<DocScrutinizer05>
there sometmes are exploits when somebody discoovers that e.g. a chunk of memory in a particular function first gets assigned to a new process' virtual addr space before it gets locked in old former owner process
<DocScrutinizer05>
usually those flaws in kernel get fixed during hours
<P-G>
So basically it's writing to unallocated memory?
<DocScrutinizer05>
after they go public
<ShadowJK>
But also, for example, a process can ask of the kernel "I would like to have the file /home/user/pornstash/goatporn/endowedgoat.jpg mapped into memory starting at address 19000 onwards", the kernel will say OK, and when the process tries to access address 19000, the CPU throws control to kernel, and the kernel loads 4 kilobytes from the file, into physical ram, and tells the CPU that process X's address 19000 should be mapped to physical ram address something
<kerio>
P-G: inter-process communication can happen in loads of different ways
<ShadowJK>
It's kinda weird to think about at first, that every program that runs on your computer, can access address 9000, and they all see different contents there
<kerio>
they all involve the kernel at some point
<kerio>
either to set something up, or to actually pass messages around
<P-G>
Huh.
modem has quit [Ping timeout: 265 seconds]
<ShadowJK>
Huh what? :-)
<kerio>
say, for instance
<P-G>
That seems complicated. :p
<kerio>
a socket
<ShadowJK>
P-G, yes, it is :-)
<kerio>
that counts as IPC
<P-G>
Ok, I will need to look into shared allocation later. I think I might need a bit more mental capacity for that.
<DocScrutinizer05>
told ya: years of learning
<kerio>
it's insanely complicated
<P-G>
I need to start somwhere. :p
<DocScrutinizer05>
"shared allocation"?
<ShadowJK>
P-G, the stuff I mentioned isn't shared allocation as such
<P-G>
Inter-process allocation?
<kerio>
virtual addressing
<DocScrutinizer05>
there are means 2 processes can agree to share some memory chunk. No issues known in that function
<ShadowJK>
Every process has "virtual memory", that's why every process can access the same memory address, yet see different contents
<kerio>
well i mean
<P-G>
Right, that makes sense.
<kerio>
technically all the memory is "shared" by a process that's accessing /dev/kmem or whatever
<kerio>
*with a process
<ShadowJK>
The kernel decides, for example "Process firefox address 9000 maps to physical ram address 1, process chrome address 9000 maps to physical ram address 2", and the hardware deals with the translation
<DocScrutinizer05>
only that nobody but root may access that file usually
<kerio>
mh, does kmem even exist
<kerio>
in modern linuxes
<ShadowJK>
kmem is kinda special and weird and ... yeah
<DocScrutinizer05>
nobody ever touches kmem ;-)
<ShadowJK>
If two processes want to share memory, you'd typically create a file somewhere, and both processes would ask the kernel to have the file mapped into memory
<DocScrutinizer05>
for example, yes
<ShadowJK>
Typical for unix, there's more than one way to do it, of course :)
<P-G>
Oh, that's interesting.
<kerio>
mh, how do you avoid writing the file on the disk?
<kerio>
i guess you open a file in /dev/shm or /tmp
<P-G>
So Physical memory --> MMC --> Kernel --> root process/kmem --> virtual memory --> every other process?
<ShadowJK>
yes, for the "advanced course on shared memory", one would discuss the specific syscalls or methods to avoid disk activity :)
<ShadowJK>
physical memory - mmu - kernel
<kerio>
mh, does a mmapped buffer always have a file descriptor, even if you created it without a path?
<ShadowJK>
kerio: cat /proc/self/maps (or any other pid instead of 'self')
<kerio>
so you can pass it around with a unix socket
<kerio>
unix is pretty fucking beautiful
<ShadowJK>
P-G, the mmu translates every memory address from every process, including the kernel. The kernel is usually the "boss", however, but not always,. In the case of running a virtualizer, the mmu might translate a kernel's requests too
<P-G>
I'm reading about MMU now. I don't know how I've never heard of this stuff.
<P-G>
MMU does not replace MMC, does it?
<ShadowJK>
Also, the CPU has "normal" and priviledged instructions, a normal process trying to execute a priviledged instruction will cause the CPU to halt the process and return control to the kernel
<ShadowJK>
MMC?
<P-G>
Memory controller.
<P-G>
Aggregates physical memory sectors.
<P-G>
Between chips and DIMM. Unless I'm crazy.
<DocScrutinizer05>
that's transparent to the users of RAM
<P-G>
Yes.
arcean has joined #neo900
<P-G>
It isn't integrated into MMU though, right?
<P-G>
Still on the chipset?
<DocScrutinizer05>
you typically not even think about it existing
<P-G>
Most people don't think about memory allocation at all. :p
<DocScrutinizer05>
it's the next thing after MMU and it basically interfaces the MMU to the chip's environment
<kerio>
is the mmu a separate chip, nowadays?
<DocScrutinizer05>
no
<DocScrutinizer05>
It probably supped being a separate chip in 1986
<DocScrutinizer05>
stopped*
<P-G>
MMC is sometimes intrgrated into north bridge, right?
<DocScrutinizer05>
not on ARM ;-)
<P-G>
:D
<P-G>
I don't like all the chipset integration.
<P-G>
QPI is fast but not fast enough for PCIe.
<ShadowJK>
x86 has mem8ry controller on-die these days
<DocScrutinizer05>
MMC is a physical thing, while MMU is a "logical" thing (though of course with a physical implementation)
<P-G>
Ok, I think I get the general idea.
<ShadowJK>
(and graphics...)
<P-G>
But kernel sometimes oversees MMU and sometimes does not?
<P-G>
Depending on... Firmware?
<ShadowJK>
The first thing that runs in the CPU has full control, and might or might not relinquish that over to a kernel
<ShadowJK>
In the classic PC, BIOS runs first, loads the kernel and hands over all control
<kerio>
*bootloader
<P-G>
Right.
modem has joined #neo900
<P-G>
Or boot strapper?
modem has quit [Changing host]
modem has joined #neo900
<P-G>
Ok so if MMU control is given to kernel, kernel uses memory to store a table mapping physical memory ranges to virtual? That's exactly one program that has access to physical memory?
<P-G>
Aside from the kernel itself, of course.
<P-G>
Or is the kernel one big PID?
<ShadowJK>
"yes"
<P-G>
Ok, that does it. I'm installing linux. No more procrastination.
<ShadowJK>
On a processor, there's only one thing every running, really, before the kernel passes over the CPU to another process, it will of course make sure that memory mappings are appropriate for that process
<ShadowJK>
This is roughly the same in Windows, except the terminology is different :-)
<P-G>
One thing per core?
<DocScrutinizer05>
I called it "any arbitrary contemporary Os" iirc
<ShadowJK>
Multicore and hyperthreading confuses things further :-)
<DocScrutinizer05>
hehehe
<DocScrutinizer05>
let the fun start ;-)
<P-G>
Kernel handles processor core and register allocation as well, right? That's enough info for me right now.
<ShadowJK>
Multicore is kinda like schizophrenia
<P-G>
Well that's good. >.<
<DocScrutinizer05>
the kernel gets executed by processor cores and in registers
<ShadowJK>
Though the hardware ensures that the system behaves as if there was a single MMU
<ShadowJK>
Except in the case of very large systems
<DocScrutinizer05>
so it's pretty hard to say if "kernel handles cores"
<P-G>
Well, let's see...
<kerio>
and we haven't even talked about PAE
<DocScrutinizer05>
rather cores handle kernel
<ShadowJK>
God, leave PAE out of this.
<P-G>
Either the kernel hands off processes to the processor or the kernel handles the processes internally, right?
<DocScrutinizer05>
LOL
<kerio>
P-G: the kernel is code that runs on the cpu
<P-G>
Yes, I know that much. :p
<DocScrutinizer05>
either your brain tells you what to do, or you tell your brain X-P
<kerio>
there's no "handing off processes"
<P-G>
Ok so kernel handles processing internally?
<DocScrutinizer05>
the kernel is software, cores are hardware
<kerio>
there's a bunch of privileged instructions that the kernel use that tell the cpu "ok, run the next handful of instructions in this memory space"
<P-G>
Ok so it's multi-plexed between cores?
<DocScrutinizer05>
please can we stop discussing multio-core for now at least?
<ShadowJK>
P-G, there are many ways to think about it, but, for many circumstances, the kernel isn't a separate discrete process in its own. It's like this "other half" of every program, except instead of the programmer writing that other half, that other half has already been written by the kernel coders. The kernel gets back control whenever an interrupt happens. An interrupt could be a hardware interrupt, a mmu interrupt, or a software interrupt (the program explicit
<ShadowJK>
ly wants to make a request to the kernel)
<DocScrutinizer05>
as long as not even single-core multitasking and mamory alllocation and per process address spaces are established yet
<ShadowJK>
Thsi means that on a multicore system you've got multiple kernels all executing simultaneously, maybe
<kerio>
with some locking for other stuff
<P-G>
Ok, I find this all very educational but we can stop if it's bothing you. I don't want to be too distracting.
<ShadowJK>
The kernel programmers obviously have decided how these kernels will speak to eachother, if they need to, for purposes of moving tasks from one core to another, for example...
<DocScrutinizer05>
multi-core is a distration for sure
paulk-collins has quit [Quit: Quitte]
lexszero has joined #neo900
<P-G>
Very interesting stuff.
<DocScrutinizer05>
start at preemptive multitasking and how per-process virtual address space gets established
<kerio>
yeah multi-core is way too distracting cuz the neo900 is monocore :>
<P-G>
Oh, is it?
<DocScrutinizer05>
how kernel is "PID0" and everything a child of kernel
<kerio>
DocScrutinizer can't into dual core
<ShadowJK>
To further complicate matters, in Linux there exists "kernel processes", that have the elevated priviledges as the kernel has, but can also be scheduled to executed as a process.
<P-G>
>_>
<kerio>
the ones that show up as "[name]" in top or ps
<DocScrutinizer05>
*sigh*
<P-G>
That really doesn't seem necessary.
<kerio>
yes it is
<kerio>
better stats
<DocScrutinizer05>
it's necessary since the kernel itself internally also does multitasking
<DocScrutinizer05>
not exactly preemptive, but... let's ignore that for now
<ShadowJK>
Also if there's heavy work that the kernel wants to do, it can assign this work to a "kernel process", and this heavy work can get scheduled along with other processes, subject to prioritization and other things
<kerio>
i wonder if this is the right time to introduce the virtualization extensions
<ShadowJK>
This makes it able for the kernel to both respond to stuff quickly, and also to do work
<ShadowJK>
kerio, no!
<kerio>
alright alright
<P-G>
So the kernel wants to stay light so it can thread more frequently?
<ShadowJK>
Well yes
<DocScrutinizer05>
DOM0 X-P
<kerio>
they're not threads tho
<DocScrutinizer05>
rings
<kerio>
well ok the distinction kinda blurs at the kernel level
<kerio>
DocScrutinizer05: fuck xen
<kerio>
real men use kvm
<ShadowJK>
lol
<kerio>
it's debian stables all the way down
<P-G>
So kernel is just one process, right? But it outsources to high-priority processes, which it gives elevated permissions?
<DocScrutinizer05>
no
<lexszero>
kernel is not a process
<kerio>
"process" is a unix term
<ShadowJK>
P-G, in this context, the kernel is not a process in its own
<kerio>
a concept
<DocScrutinizer05>
kernel is creator of processes
<P-G>
Ugh, ok.
<lexszero>
but it has some internal process entities
<ShadowJK>
P-G, it outsources to processes because it isn't a process :-)
<P-G>
So not PID0?
<kerio>
whether or not a process is matched by some data in the CPU depends on the architecture
<DocScrutinizer05>
there's no PID0
<lexszero>
to have the very concept of pid, you need a kernel first
<kerio>
"morally" it's pid 0
<DocScrutinizer05>
since PID1 is child of kernel
<kerio>
it transcends process IDs
<DocScrutinizer05>
all other processes are childs of PID1
<lexszero>
pid1 is not a "child" of kernel. it's started by kernel, and if it dies, kernel panics.
<kerio>
it could be pid -1
<P-G>
So PID1 allocated all other processes?
<lexszero>
yes.
<kerio>
this is unix-specific stuff
<kerio>
ignore the hardware stuff
<P-G>
Doesn't apply to linux?
<kerio>
pretend you have some magic box that lets you do unix things
<kerio>
like the linux kernel
<kerio>
init exists
<DocScrutinizer05>
lexszero: by whatever definition of "child", you said yoourself that kernel "starts" PID1
<kerio>
init is a process
<DocScrutinizer05>
actually it rather forks it
<kerio>
so like every other process, it has ways to run more processes
<kerio>
usually by fork()ing and then exec*()ing
<ShadowJK>
P-G, in close up detail, the kernel tells the cpu "You will assign physical addresses I to J to virtual X to Y, and execute with regular priviledges starting at X+1. If there's an issue or interrupt, you will map addresses a to b into c to d, and execute c+1". The kernel being a to b, etc....
<lexszero>
the "child/parent" is also the unix concept. it's doesn't reflect relations between kernel and pid1.
<DocScrutinizer05>
well, by your definition of "child"
<kerio>
the traditional sysV init reads inittab and launches some scripts
<ShadowJK>
So more or less, the kernel doesn't exist unless there's an "issue"
<DocScrutinizer05>
my children are not unix processes
<DocScrutinizer05>
;-)
<DocScrutinizer05>
PID1's parent is not a process either
<kerio>
i hope your children are humans
<lexszero>
kernel provides an abstraction for userspace
<ShadowJK>
There's that
<ShadowJK>
On a hardware level, it happens through interrupts
<ShadowJK>
an interrupt is one of "if there's an issue"
<lexszero>
that abstraction includes processes, memory, files, etc
<DocScrutinizer05>
fine. And how does this help with MMU
<lexszero>
i've missed original question, can you repeat?
<kerio>
yeah i dunno why we're talking about linux
<kerio>
let's talk about how linux started
<lexszero>
why talk about that?
<kerio>
aka a real-mode x86 program that wrote AAAAAAAAAAAAAAAAAAA and then wrote BBBBBBBBBBBBBB
<kerio>
apparently, linus' sister wasn't too impressed
<P-G>
So if there's an issue, the kernel is run as a script from memory and it effectively restarts the system without killing any processes or clearing any memory? Kernel uses that opportunity to preform maintenance then hand off processor to next program?
<kerio>
but that was a tiny kernel that ran two programs
<ShadowJK>
That utilized the 386 processor's hardware multitasking capabilities
<kerio>
yep
<ShadowJK>
these days no OS uses the hw multitasking
<lexszero>
x86 arch is full of legacy that makes linux startup hard to describe in a few words. if you really interested, you can read UTLK or another similar book
<ShadowJK>
lexszero, it's not startup that's the question here
<kerio>
the question was "how does virtual memory work?"
<P-G>
I will add that to my list. ;)
<kerio>
and we ended up at sysV init, for some weird reason
<P-G>
Well, we were talking about how memory is handled by the big black box that isn't a program. :p
<ShadowJK>
lexszero, it more or less started by trying to correct P-G's assumption that any process can write over any other processes's memory space, and his belief that trusted computing was going to solve this. We've been trying to bring him up on the basics of protected memory, MMU and stuff since then
<DocScrutinizer05>
the initial question was "isn't TrustedComputing a good thing? With all those mem alloc exploits they always report about"
<kerio>
oh right
<P-G>
Sorry. ;(
<kerio>
it's not like trusted computing would solve bugs
<P-G>
I thought it provided memory isolation. ;(
<P-G>
I know I'm a disappointment.
<lexszero>
VM is just a translation of hardware memory adresses to that ones used by processes. so process' A acesses to address X and process' B accesses to the same address X leads to different physical memory cells
<DocScrutinizer05>
my answer been that TC won't help when your system sufers such an exploit, since the system is already pawned when an app achieves privilege escalation
<DocScrutinizer05>
lexszero: literally same been said before
<lexszero>
MMU has a table that specifies how current process' virtual addresses maps to physical. and if process tries to access address that not mentioned in that table, it asserts to the kernel that decides what to do.
<P-G>
I understand now.
<P-G>
That's how we started talking about the kernel. :p
<ShadowJK>
lexszero has better articulated summary than our ramblings though
Pali has quit [Remote host closed the connection]
<DocScrutinizer05>
I just wonder if it helps out P-G
<lexszero>
I have a few years of kernel development experience, so you can ask me about that kind of things
<P-G>
Oh yes, I've learned a lot. :)
<P-G>
You guys are all great.
<DocScrutinizer05>
:-)
<P-G>
I've been afraid of the kernel for years.
<DocScrutinizer05>
nah, kernel is a nice guy :-)
<kerio>
lexszero: how's the process specified, on the hardware side?
<lexszero>
nothing to fear there, it won't kill you, just crash everything :D
<kerio>
a numerical id?
<kerio>
does it match unix PIDs?
<lexszero>
process is fully implemented in software
<P-G>
That's PID1, right?
<lexszero>
no, it's a kernel
<kerio>
oh i see, whenever you're about to taskswitch you update the virtual memory definitions
<lexszero>
i mean kernel cares about process switching, telling MMU to look at the table of currently running process and vice versa
<P-G>
So I thought PID1 handled process creation.
<kerio>
no, that's the kernel
<kerio>
pid 1 is little more than a shell script
<kerio>
pid 1 is a process
<lexszero>
there are a separate MMU table for each process, and task switch is basically saying to MMU to use that one of next process and jump to instruction next to one that was last executed when process was preempted
<kerio>
alright
<lexszero>
there are a lot of optimisations around this basic scheme, but its all unimportant for overview
<P-G>
I think I understand the virtual memory concept and the purpose, if not exact format, of the tables.
<ShadowJK>
Let's introduce the concept of IOMMU and confuzzle everyone again :D
<P-G>
I just want to make sure I've got this part straight. The kernel is basically a script that runs whenever a process ends or breaks?
<lexszero>
format is architecture specific. each entry basically has virtual range, physical range and some flags (can read, write, execute, ...)
<P-G>
And the kernel does things like adjust priority of processes then hands off to the next process in line?
<lexszero>
kernel is a piece of code that manages processes
<DocScrutinizer05>
kernel creates excatly one process by itself: pid1. Pid1 then creates more processes using kernel's facilities
<lexszero>
and handles I/O
<DocScrutinizer05>
and IRQ, and timers
<DocScrutinizer05>
and...
<P-G>
But the kernel always runs from beginning to end whenever it gets it's turn?
<DocScrutinizer05>
yes
<DocScrutinizer05>
well, err "from beginning to end"?
<lexszero>
kernel has no "end", it's something like infinite loop
<lexszero>
so it ends when you turn your machine off
<DocScrutinizer05>
that's what I meant :-)
<kerio>
something something kexec
<lexszero>
and the kernel is not running all the time: if this was true, processes can't execute
<P-G>
No, I understand that part.
<DocScrutinizer05>
actually kernel "process" finally turns into scheduler
<DocScrutinizer05>
aiui
<P-G>
So it runs about 2-4 times as frequently as other processes?
<kerio>
DocScrutinizer05: and all the syscalls
<DocScrutinizer05>
it actually runs as frequently as all other processes togeter, plus some
<P-G>
Wow.
<P-G>
So it gets a turn after every process ends?
<DocScrutinizer05>
every process gets called when it's up to him, by kernel. and kernel will run when the process gets preempted
<lexszero>
it's not running the full its code when processes are switching or interrupt assertion, only a small part that just does the things needed right now
<DocScrutinizer05>
yes
<kerio>
he doesn't "get" a turn
<kerio>
he's not a player character, he's the dungeon master
<DocScrutinizer05>
exactly
<lexszero>
nice analogy :)
<DocScrutinizer05>
the scheduler
<P-G>
But only one process can be loaded into the processor at a time, assuming one core?
<P-G>
Thus turns from multiplexing?
<DocScrutinizer05>
yes
<kerio>
the cpu will execute an instruction at a time
<kerio>
if it could execute two instructions, it would be a dual core cpu
<P-G>
Right.
<DocScrutinizer05>
eventually a hw timer will interrupt §arbitrary-process and the control is back to kernel/scheduler
<lexszero>
CPU executes only one instruction at a time. it can be instruction belongs to kernel or to some process
<P-G>
So the HW timer runs in CPU firmware?
<lexszero>
HW timer is a purely hardware thing
<DocScrutinizer05>
scheduler decides which is next in queue and passing the execution to that process
<P-G>
Scheduler is kernel?
<lexszero>
kernel tells them when to fire next time
<DocScrutinizer05>
yes
<lexszero>
yes, it's a kernel subsystem
<P-G>
So processor runs on one process until the timer expires then kernel loads up the next process?
<P-G>
And resets the timer?
<lexszero>
yes, kinda
<DocScrutinizer05>
it's basically the final loop "that never exits", in kernel's code that gets started by bootloader
<DocScrutinizer05>
and yes
<P-G>
I understand that part but allocating processor time and managing RAM are the questions.
<P-G>
Those two are basically the same thing I guess.
<DocScrutinizer05>
kernel has a book of process descriptions
<P-G>
Like copy x to y?
<DocScrutinizer05>
for each process to run, kernel/scheduler prepares the environment so the process doesn't even notice it got interrupted
<kerio>
cpu opcodes are kinda like that, yeah
<kerio>
except that they're more like "copy the word pointed at by this register into this other register"
<lexszero>
processor commands is "take a number from address X and put to address Y"
<DocScrutinizer05>
part of that preparation is to set up the MMU tables for process' virtual adress space
<DocScrutinizer05>
alocating CPU time is done by scheduler deciding which process is next to run
<DocScrutinizer05>
usually that's the process who needs CPU most
<P-G>
And that's kernel, right?
<lexszero>
yes
<DocScrutinizer05>
see process priority
<P-G>
But MMU table is only changed by the kernel or also the relevant process?
<DocScrutinizer05>
man nice
<kerio>
only the kernel
<lexszero>
no, process can't change mmu tables
<kerio>
the process can ask the kernel nicely to do stuff like give him some more memory
<kerio>
or mmap a file
<P-G>
Ok, so the timer must be very short or hand off to kernel frequently?
<DocScrutinizer05>
that would be pretty bad ulnerability if processes could change mmu tables
<lexszero>
yes
<kerio>
let's put it this way
<lexszero>
on typical desktop linux timer is about 1-10 ms
<kerio>
if your computer is playing two 60fps videos at the same time, you're task switching at least 60 times each second
<kerio>
in reality, it's much much much much more frequent than that
<kerio>
mh ok actually maybe it's only much much mor
<kerio>
*more
<DocScrutinizer05>
as lexszero said: 100 to 1000 tines per second
<P-G>
So kernel runs when a process ends, breaks, or tried to allocate memory?
<DocScrutinizer05>
though you can tweak that to your liking, as root/sysadmin
<lexszero>
yes, and there are a lot of other situations
<P-G>
Such as?
<kerio>
on linux, any syscall
<P-G>
Access violations.
<lexszero>
like interrupt from some device
<DocScrutinizer05>
yes, often processes don't expire their time slot but run into a stop situation
<kerio>
no like opening a file
<kerio>
writing to a socket
<lexszero>
e.g. hdd is finished read operation and notifies kernel about this
<P-G>
So basically anything that's not math or writing memory?
<kerio>
pretty much, yeah
<ShadowJK>
(and in some cases also writing to memory)
<DocScrutinizer05>
and as lexszero said there are async interrupts too
<lexszero>
yes. jumping to some other instruction inside one process is done without kernel intervention too.
<P-G>
Ok. And kernel's usual job is just to adjust process priority, maintain I/O, and then hand off to next process?
<DocScrutinizer05>
yes
<lexszero>
and respond to requests from processes, that called 'syscalls'
<kerio>
P-G: anything that involves the rest of the hardware also needs something done in the kernel
<P-G>
Syscalls break the process though, right? So you would only ever have one to deal with at a time on a single core processor?
pigeons has joined #neo900
<P-G>
One per kernel turn?
<DocScrutinizer05>
nope
<DocScrutinizer05>
sycalls can take quite long to finish
<DocScrutinizer05>
in the meantime other processes run and do syscalls too
<lexszero>
kernel is not adjusting priorities, it's ensures that the priorities are taken into account when selecting what process to run next
<P-G>
Oh, so it just hands off?
<lexszero>
syscall is something like a function that requires kernel to do something for the process
<lexszero>
*function call
<P-G>
Ah, ok.
<P-G>
Like copying files?
<DocScrutinizer05>
err, well.... yes
<DocScrutinizer05>
sort of
<ShadowJK>
file copy is kinda advanced
<P-G>
Just the idea. Ok.
<ShadowJK>
File copy is not a single operation :-)
<DocScrutinizer05>
memcopy is
<DocScrutinizer05>
;-)
<ShadowJK>
File copy can be like ... a gazillion operations
<lexszero>
copying files is a whole bunch of syscalls. open file A, open file B, read from A, write to B, repeat
vakkov has quit [Ping timeout: 244 seconds]
<P-G>
Ok, that makes sense.
<kerio>
lexszero: well
<DocScrutinizer05>
let's say "getsystime()"
<kerio>
sendfile(2)
<kerio>
but that's kinda sorta cheating
<P-G>
Surprising you can't just copy the data range off the drive but I guess that would introduce potential incompatibilities.
<kerio>
P-G: sure but
<kerio>
you still have to read the data and write the data somewhere else
<kerio>
and then you still have to deal with all the stuff around the data
<P-G>
Right but no opening/closing files.
<DocScrutinizer05>
theprocess asks kernel "gimme current time". That's a syscall. Process stops. Kernel does whatever is needed to decide what's the time, then starts porcess with the result in place
<P-G>
Deletion and such.
<lexszero>
and all this open, read, write etc operations is complex things, involving a lot of kernel work
<kerio>
not to mention that the data might not be all together
<P-G>
Ok, ok. Priorities.
<P-G>
Too much to learn. :p
<P-G>
I need to learn some proper programming.
<P-G>
I think I have a better understanding of the kernel now though. Thank you.
<lexszero>
and waiting for hardware to do it's work, so the process is suspended as DocScrutinizer05 said, meanwhile other processes executed, and finally the original processes resumed
<P-G>
You wouldn't actually need to wait for the hardware operation to finish depending on what it is though, right? South bridge would handle I/O once it's started?
<DocScrutinizer05>
NONBLOCK call
<DocScrutinizer05>
yes
<P-G>
Non-block?
<P-G>
Doesn't block the processor or it doesn't use a block in the process order?
<lexszero>
but then the process should repeatedly poll "is it done? is it done?"
<DocScrutinizer05>
a lot of syscalls have a NONLOCK flag that tells kernel to not stop process
<DocScrutinizer05>
NONBLOCK*
<lexszero>
to get result
<kerio>
well
<kerio>
the idea is that you don't poll in a loop
<P-G>
Hm.
<kerio>
you do other stuff
<kerio>
there's lots of ways to do "multiple operations at once"
<DocScrutinizer05>
and evetually come back to check if kernel fiished the task for you
<P-G>
Ok, well, I will try reading this book, Understanding the Linux Kernel, 3rd edition. Is it up to date if it was published in 2005?
<lexszero>
yes, but sometime in a future, you must do another syscall to get what you need
<lexszero>
the basic conceptions doesn't change
<kerio>
P-G: hold on weren't you about to install linux like 10 minutes ago
<DocScrutinizer05>
yep :-9
<DocScrutinizer05>
:-)
<lexszero>
that book is oriented for kernel programmers, so it may be a hard thing to read for you
<DocScrutinizer05>
ouch
<DocScrutinizer05>
indeed
<P-G>
I will install linux. I promise. :p
<lexszero>
so wikipedia can be a good starting point
<P-G>
Maybe not tonight, but tomorrow.
<kerio>
no i meant like
<kerio>
reading a book about the details of kernel programming is probably not the best idea
<kerio>
if you've never even installed the damn thing
<DocScrutinizer05>
kerio: don't worry, it still counts as *NIX of sorts ;-P
<kerio>
so pretty
<kerio>
:3
<kerio>
"of sorts" he says
<kerio>
1) the usual gnu and bsd stuff
<kerio>
2) no systemd
<DocScrutinizer05>
MACH kernel ;-P
<kerio>
hey, darwin is cute
<P-G>
Ok, I'm going to go AFK. I will look at the book before buying but I do like to know how things work so I'm not afraid to learn as long as the information is good.
<lexszero>
every OS kernel has similar stuff - scheduler, memory management, etc. even windoze. minix is a very basic unix-like kernel specially developed for educational purposes.
<DocScrutinizer05>
P-G: the great thing about linux: it's basically just another UNIX, and all you learn will be applicable to so much more than just linux
<P-G>
The real selling point for me is that there are so many distributions with the same kernel. Even if one goes horribly wrong (Unity), the others are fundamentally the same.
<P-G>
When Windows does something stupid, you're stuck with it.
<kerio>
nt does stupid shit all the time
<kerio>
like calling kernel code from a fucking scrollbar callback
<DocScrutinizer05>
when linux does something wrong, you go *NIX