logs archiveBotHelp.net / Freenode / #2f30 / 2015 / August / 6 / 2
stateless
that's insane
:P
2M for kernel stack is insane
but good luck :P
tm512
then I'll just keep my bootstrap stack
which is 4k reserved in the kernel binary
stateless
u need one kernel stack per process
tm512
oh right
stateless
ideally that is
:)
tm512
TSS bullsh*t?
stateless
you can do it by hand
but yes tss is one way
i hate tss
tm512
well interrupts will need to stay safe from other interrupts
stateless
yes
tm512
so yeah I'll have to swap stacks when I preempt processes
stateless
well u can have a shared interrupt stack
i think
tm512
so yeah I'll have a simple kalloc or something
stateless
yeah
it is convenient even if u do a microkernel
and u have most stuff out of the kernel
so if u keep ur page frame allocator compact
tm512
anyway rounding up each portion of memory that GRUB says is free to the nearest page boundary
stateless
u will get better cache locality
tm512
then going to iterate until the end
stateless
but u know, nodes can easily be 64 bytes apart
tm512
this is relatively easy to replace
stateless
(with a list based approach)
yes, the easiest and most compact form is a bitmap :P
not always
but good enough
tm512
the list approach seems easy
stateless
u might still be jumping around but u can optimize that later
just a bit suspicious because u will have lists for vmem alloc and lists for pmem alloc
but try it
see how it works with the list approach
it won't matter much initially
so generally pick the easiest approach for everything
it will become a nightmare to debug very quickly when u turn on smp
tm512
smp isn't really a thought for me yet
stateless
right well u can still race with interrupts
:P
plus the ipc stuff u will have
tm512
http://wiki.osdev.org/Page_Frame_Allocation#Stack.2FList_of_pages
might eventually go on to a buddy scheme
or bitmap
stateless
so yeah some way to lock it down to debug would be nice (big kernel lock? :D:D:D)
i used bitmap
tm512
this isn't a lot of code
and it's pretty decoupled from the rest of the system (which only will care about getting a page, it doesn't care how)
stateless
yeah
tm512
so it should be easy to swap out if necessary
stateless
at a later point you might want to keep in mind special regions
special phys regions
tm512
for DMA and stuff?
stateless
yes
so u do not return dma-able regions for general purpose allocations
have some special func for that
tm512
or I could have a slower DMA allocator
stateless
to ensure u will always have dma-able memory
tm512
that scans the list for contiguous space
but it could be slow
stateless
yes but the phys frame allocator needs to know to exclude that
for arm i mean this would be necessary
because everything is memory mapped
so depending on the board configuration
u have reserved regions to control peripherals
etc.
which are fixed per board
FRIGN
hey ;)
I'm back
stateless
but the same IC could be at different offsets on different board configs
hi FRIGN
tm512
this could possibly be done before the page frame allocator gets to the memory
stateless
yes
or have the kernel allocate them all to itself
then the page frame allocator will see them as in use
FRIGN
stateless: they discussed sbase again on cat-v
stateless
then a virt mem allocator can be used to grab those pre-existing mappings
well ok there are many ways
doesn't matter for now
tm512
yeah, I can get something else working when what I have won't work
stateless
:)
tm512
http://hastebin.com/raw/ocihonezey
seems fine so far
whoops no it's totally not fine
http://i.imgur.com/13wqSCb.png ;)
kori
tm512: cool cool
k0ga
morning
kori
hi
stateless
yo
k0ga
yo
retard
YYYYYYYYOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!
stateless
hey retard check your switch man
your duplex switch is stuttering
retard
i'm doing a bit
like this https://www.youtube.com/watch?v=EtQbmtHe9lo
stateless
haha
« prev 1 2 3 4 next »