<OscarL>
pairisto[m]: I might be wrong but... (as long as nobody else answers you :-D) ...
<OscarL>
pairisto[m]: I don't think you're supposed to do it that way. If BufferQueue.{h|cpp} is generic enough as to be used by multiple modules, perhaps its should be moved to "headers/private/kernel/util" (.h) and "src/system/kernel/util" (.cpp). At least that's how other data structures / classes seems to be shared among kernel code.
<OscarL>
either that, or I guess you could just copy/paste them next to your "tun_driver.cpp", at least while testing things out.
<OscarL>
Surely I'll piss off some real dev with how wrong I am, and you'll get a better answer anyway :-D
<pairisto[m]>
I decided on the copy paste lol
<pairisto[m]>
since it just didn't want to work so whatever ¯_(ツ)_/¯
<pairisto[m]>
* since it just didn't want to work so whatever ¯\_(ツ)_/¯
Maturi0n_ has joined #haiku
phcoder has quit [Quit: Connection closed for inactivity]
<pairisto[m]>
also, is it okay to test a driver with python or should I make a C file?
<pairisto[m]>
s/file/program/
<OscarL>
There is already some python code in haiku's tree, so I would assume any test better than no test (whatever the language :-D). But as always... I'm just another user, not a dev.
selfish- has quit [Read error: Connection reset by peer]
<OscarL>
(I also use python to do some of my tests on BSerialPort / serial_mouse)
<pairisto[m]>
I was thinking python is quick enough but can't use the traditional open/read/write
selfish has joined #haiku
<OscarL>
prototype in python, then .cpp, works for me. (did so for a pkman feature that I should probably upload for review one of these days).
<OscarL>
*pkgman
Maturi0n has quit [Ping timeout: 480 seconds]
<pairisto[m]>
fair enough, so long as I stop kernel panicking the system -_-
<OscarL>
ah... been there. "fun" times :-D
HaikuUser has joined #haiku
<augiedoggie>
ew, the github interface changed for me
* augiedoggie
wants the old version back
<OscarL>
augiedoggie: you can turn it to the old one, at least for now.
<OscarL>
lemme see if I remember how I did that.
<OscarL>
I think I've just disabled "Global Navigation Update" from "Features Preview".
<augiedoggie>
probably only a matter of time until they force it on me :P
kikadf has joined #haiku
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
HaikuUser has joined #haiku
HaikuUser has quit []
probono9 has quit [Quit: Ping timeout (120 seconds)]
probono9 has joined #haiku
linuxmaster has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
Guest1520 has quit [Ping timeout: 480 seconds]
moparisthebest has joined #haiku
moparisthebest is now known as Guest3553
phschafft has quit [Ping timeout: 480 seconds]
AlaskanEmily has quit [Ping timeout: 480 seconds]
phschafft has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
DKnoto has joined #haiku
Begasus has joined #haiku
<Begasus>
g'morning peeps
Begas_VM has joined #haiku
<erysdren>
good morning Begasus
_Dario_ has quit [Quit: Vision[]: i've been blurred!]
<Begas_VM>
good morning erysdren
HaikuUser has joined #haiku
HaikuUser has quit []
korli has joined #haiku
<korli>
pairisto[m]: hi
OscarL has quit [Remote host closed the connection]
dryphb has quit [Ping timeout: 480 seconds]
freddietilley has joined #haiku
Diver has joined #haiku
AKEmily has joined #haiku
<Begas_VM>
bonjour korli :)
dryphb has joined #haiku
<Begasus>
think we can move lua5.4 as default now? (has been around for a while and lua5.3 hasn't seen any changes over 3 years)
<Begasus>
so far not a lot of recipes are "using" lua
<Habbie>
do it :)
<Begasus>
err ... about 50 hits for lib:liblua :)
<Begasus>
evan one for 5.1 :P (quick look)
<Begasus>
devel:liblua is a better reference, conflict is only for liblua.so (in devel package)
AKEmily has quit [Remote host closed the connection]
qwebirc23986 has joined #haiku
qwebirc23986 has quit [Remote host closed the connection]
kescher_ has joined #haiku
kescher has quit [Read error: Connection reset by peer]
kescher_ is now known as kescher
<korli>
Begasus: what means default? shouldn't each app define the required version?
<Begas_VM>
for the cmd's korli
<Begas_VM>
atm only lua5.3 provides "cmd:lua"
<Begas_VM>
for the devel package most already define a required version
<Begas_VM>
the manpages are also renamed
<korli>
ok
<Begasus>
PR just created
HaikuUser has joined #haiku
HaikuUser has quit []
<erysdren>
Begasus, how do i use wget in a recipe (to download the data of a freeware game, for example?)
<Begasus>
cmd:wget?
<Begasus>
better would be if you would grab it with SOURCE_URI_2
<erysdren>
ah i didnt know i had that
<erysdren>
where does that get extracted to?
<Begasus>
atleast you can have a checksum on that
<Begasus>
sources2 ($sourceDir2)
<erysdren>
cool thanks
<erysdren>
CHECKSUM_SHA256_2?
<Begasus>
should be plenty examples at haikuports
<Begasus>
yep
<Begas_VM>
korli, -DLUA_COMPAT_5_3 set this as compat >= 5.3 in the recipe for lua5.4, not changing that for lua5.3 (uses -DLUA_COMPAT_5_2) to break some deps there
<Begasus>
would be nice to see frozen-bubbles again on Haiku ...
MajorBiscuit has joined #haiku
mmu_man has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
selfish has quit [Ping timeout: 480 seconds]
CPYou has joined #haiku
CPYou has quit [Remote host closed the connection]
<pairisto[m]>
I've got a question, I have my driver [here](https://github.com/Swangeon/HCC/blob/main/driver.cpp#L176) and every time I call write on the driver, it kernel panics with a bad address error? any reason why as I have exhausted my reasons.
ClaudioM has quit [Quit: leaving]
CPYou has joined #haiku
DKnoto has quit [Ping timeout: 480 seconds]
<Habbie>
pairisto[m], can you show the error?
<Habbie>
i tested %li on a size_t* here (although not on Haiku) and that seems fine
<Habbie>
pairisto[m], does _read work?
<pairisto[m]>
read is fine, give me one sec to get a screenshot of it
jmairboeck has quit [Quit: Konversation terminated!]
<Habbie>
you're using python to write to your tun device?
<pairisto[m]>
yeah, thought it was just quicker
<Habbie>
oh yes
<Habbie>
not a complaint
<Habbie>
just checking :)
<pairisto[m]>
np :)
<Habbie>
to be clear, i've done a lot of C++ but not much haiku
<Habbie>
so if i ask stupid questions, bear with me :)
<pairisto[m]>
np!
<Habbie>
ok, so bottom half of the screenshot is user space, eventually doing _kern_write, that makes sense
<Habbie>
can you maybe find out the arguments to your tun_write?
<Habbie>
naively, the only thing i can see failing is your pointer deref *numbytes
<Habbie>
because it hasn't made it into dprintf
<pairisto[m]>
so from when it was working before, data was whatever I put into the write function, numbytes was length of the data, cookie is something else that the kernel holds and is just NULL rn, don't know what offset is
<Habbie>
off_t position? it's not a thing for a network driver
<Habbie>
(it would be for a file)
<Habbie>
(if i got this right)
<pairisto[m]>
sorry, meant position not offset
<Habbie>
np
<pairisto[m]>
I am gonna see it just keeping it as return B_OK will still panic
<Habbie>
good test
<pairisto[m]>
* I am gonna see it just keeping it as return B\_OK; will still panic
<Habbie>
finding out the arguments in KDL would be good though
<pairisto[m]>
how do you find the arguments passed in KDL?
<Habbie>
i have no idea
phcoder has quit [Quit: Connection closed for inactivity]
<pairisto[m]>
Habbie: fun fact, it still panics when it just returns B_OK T_T
<pairisto[m]>
I think it has to be something with the arguments
<Habbie>
can you maybe get gdb to give you a disassembly of your tun_write? so we can see what is at +0x27?
<PulkoMandy>
pairisto[m], you can't access userspace memory directly like this
<PulkoMandy>
(you are dereferencing numbytes)
<PulkoMandy>
you need to use user_memcpy to access it
<Habbie>
in that case, i suggest the test without the deref is actually running old code
<Habbie>
but, good, that explains the previous run at least
<Habbie>
PulkoMandy, is 0x18 an expected value for that numbytes pointer?
<PulkoMandy>
no
<PulkoMandy>
looks like there is a null pointer somewhere
<Habbie>
to a struct, no doubt
<PulkoMandy>
I would carefully review the previous steps, in particular if the open() did everything it is supposed to
<pairisto[m]>
wait then why does it still panic even after I changed it to just return B_OK;
<pairisto[m]>
open only does a dprintf and that works fine
<PulkoMandy>
open is responsible for creating the "cookie" that is then passed to other functions. If multiple things have opened your device, this is how you know which of these is calling the other functions
<PulkoMandy>
are you sure that you are running the latest version of the modified code?
<pairisto[m]>
I'll recompile again and make sure
<Habbie>
the 0x18 still baffles me in that case, but i'll hold for your further checks :)
<pairisto[m]>
where is the 0x18?
<Habbie>
first line of both screenshots
<PulkoMandy>
on the first line of the panic, it sjows which address triggered a problem
<Habbie>
and i'm assuming that's the address you tried to read
<Habbie>
ack
<PulkoMandy>
in this case it is 0x18 which looks suspiciously close to 0 (the NULL pointer)
<Habbie>
yeah
<pairisto[m]>
hmmm
<Habbie>
so my guess it's into a struct
<Habbie>
but PulkoMandy said it doesn't make sense for numbytes to point at 0x18 and if you're just returning B_OK i'm extra out of explanations
<PulkoMandy>
I think you are disassembling the stack and not the function itself
<Habbie>
yeah
<PulkoMandy>
doesn't just yping "dis" without arguments work?
<Habbie>
(the call 0x18(%rax) is interesting, though)
<pairisto[m]>
yeah thats why I was thinking it was still in tun_write
<pairisto[m]>
s/tun_write/tun\_write?/
<pairisto[m]>
maybe I need to add the offset?
<Habbie>
to what?
<PulkoMandy>
first of all disassemble from an address that points to the code you want to look at. Disassembling the stack which is just data, will make no sense
<pairisto[m]>
0xffffffff81ee9057?
<PulkoMandy>
so, yes, call 0x18(rax) and we can see rax is 0
<PulkoMandy>
so that where our access to 0x18 comes from
<PulkoMandy>
so as I said before: probably the "cookie" is not correctly initialized and you need to do actual things in the open function to allocate and initialize it
<pairisto[m]>
alright, cookie just wants a pointer to something if I am correct
<PulkoMandy>
You have added an extern C to the declaration but not to the definition (line 31)
<PulkoMandy>
So the hooks structure expects a C++ function but you define a C one
<Habbie>
oh vtables?
<PulkoMandy>
You can tell, because the undefined reference error includes the parameters
<PulkoMandy>
Not vtables, but c++ mangling
<Habbie>
oh sorry, did not read all, ignore me right now
<PulkoMandy>
In c++ you can have multiple functnons with the same name but different arguments. This is encoded in the symbol name. In C, the symbol name is just the function name
<pairisto[m]>
ah so just add ** instead of *
<PulkoMandy>
extern "C" allows to declare or define a function in a C++ file so that it can be linked in C style