cmonroe_ has quit [synthon.oftc.net larich.oftc.net]
Rayyan has quit [synthon.oftc.net larich.oftc.net]
valku has quit [synthon.oftc.net larich.oftc.net]
_0x4a6f has quit [synthon.oftc.net larich.oftc.net]
aparcar has quit [synthon.oftc.net larich.oftc.net]
kenny has quit [synthon.oftc.net larich.oftc.net]
hurricos has quit [synthon.oftc.net larich.oftc.net]
mangix has quit [synthon.oftc.net larich.oftc.net]
russell-- has quit [synthon.oftc.net larich.oftc.net]
Spr0cket has quit [synthon.oftc.net larich.oftc.net]
kerneltoast has quit [synthon.oftc.net larich.oftc.net]
agb has quit [synthon.oftc.net larich.oftc.net]
sauce has quit [synthon.oftc.net larich.oftc.net]
eigma has quit [synthon.oftc.net larich.oftc.net]
dwfreed has quit [synthon.oftc.net larich.oftc.net]
grid has quit [synthon.oftc.net larich.oftc.net]
dvn has quit [synthon.oftc.net larich.oftc.net]
arnd_ has quit [synthon.oftc.net larich.oftc.net]
Vaughn has quit [synthon.oftc.net larich.oftc.net]
swalker has quit [synthon.oftc.net larich.oftc.net]
zx2c4 has quit [synthon.oftc.net larich.oftc.net]
valku1 is now known as valku
pekster has quit [synthon.oftc.net larich.oftc.net]
Vaughn_ is now known as Vaughn
swalker_ has joined #openwrt-devel
russell-- has joined #openwrt-devel
pekster has joined #openwrt-devel
aparcar_ is now known as aparcar
_0x4a6f_ is now known as _0x4a6f
eigma has joined #openwrt-devel
agb has joined #openwrt-devel
hexagonwin has quit [Remote host closed the connection]
grid has joined #openwrt-devel
<mrnuke_>
aparcar[m]: that function name was purely for your entertainment and my testing.
danitool has quit [Ping timeout: 480 seconds]
dwfreed_ is now known as dwfreed
<mangix_>
hmmm
mangix_ has quit []
mangix has joined #openwrt-devel
<mangix>
so I just got an RT1800. Should I try for OpenWrt support?
<slh>
the question would be, why not? at least the specs suggest that doing so would have a reasonable chance of success, unless the vendor actively tried to prevent it.
clandmeter has quit [Remote host closed the connection]
clandmeter has joined #openwrt-devel
clandmeter has quit [Remote host closed the connection]
clandmeter has joined #openwrt-devel
clandmeter has quit [Remote host closed the connection]
clandmeter has joined #openwrt-devel
clandmeter has quit [Remote host closed the connection]
clandmeter has joined #openwrt-devel
clandmeter has quit [Remote host closed the connection]
clandmeter has joined #openwrt-devel
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
valku has quit [Quit: valku]
csrf has joined #openwrt-devel
<mrnuke_>
aparcar[m]: realtek-poe does not yet have an interface to power cycle a specific port. You could at some point do a /etc/init.d/poe restart to cycle all the ports, but that "feature" has since been resolved
csrf has quit [Quit: Leaving]
<russell-->
i just ordered an engenius ews2910p
hanetzer4 has joined #openwrt-devel
hanetzer3 has quit [Ping timeout: 480 seconds]
hanetzer has joined #openwrt-devel
hanetzer4 has quit [Ping timeout: 480 seconds]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
<fpsusername[m]>
Harm_: any luck with the 2gbps patch? Did you add it to your repo yet?
<fpsusername[m]>
I see openwrt has a commit of 11h ago, so I'll retry today, see if it builds
<\x>
still no multi-ssid capability but ill take it
<mkennedy>
mrnuke: Is there a reason we cannot point a ustream_fd_init at /dev/i2c-0 once it's been ioctl'd?
<mkennedy>
oops
mkennedy is now known as hurricos
<hurricos>
there we go
<hurricos>
mrnuke: I get that i2c is both sync in needing a clock and sync in that the slave cannot initiate transfers, but ...
<hurricos>
ustream_fd_init against an i2c dev won't see anything unless it reads
<hurricos>
either the same is true against the uart ttyS1, or we're opening the device file with different options
<hurricos>
if the former is true, I don't know how everyone missed this
<hurricos>
if the latter is true, which I expect, I wonder, couldn't we 'agitate' the file somehow while waiting to get ustream to see (poll for) new messages so it triggers the callback?
<hurricos>
If we can do that, we can separate medium specificity and have some companion code (e.g. uart_stream.c, i2c_stream.c) do medium setup for us
<hurricos>
then, unless there's a better idea floating around, have a poll happen somewhere, for the serial medium it's a dummy, for i2c it actually does that agitation
<hurricos>
I mean, this is what uloop is built for: lets you give it code for it to tell you to execute
<hurricos>
Oh, I see the problem now
<hurricos>
writing to the file is done using ioctl
<hurricos>
But that's not necessarily required here
<mrnuke_>
hurricos: There's a poll() system call that tells ubox there are bytes available on ttyS1. Then ubox can do a read(). Will this work for i2c-dev?
<hurricos>
yes!
<hurricos>
It will, we also just need to switch out the uh
<mrnuke_>
hurricos: from what I saw in the kernel sources, there isn't a way to initiate an i2c read. so the read() call is necessarily blocking
<hurricos>
... bkobl uses a read+write ioctl
<hurricos>
Well, we have two problems: one, that we have multi-medium-specific handling entering main.c, and the blockign bit
<hurricos>
I care more about the former than the latter
<hurricos>
blocking, yeah, not great. ubus call poe info will not respond as immediately as it could
<hurricos>
but the former is way worse, it means messy, unmaintainable, unmergeable code :P
<mrnuke_>
If both matter to some degree, and they are orthigonal, then doing both at the same time is the leaset amount of effort (It's the hypothenuse)
<hurricos>
how are you proposing to fix the latter?
<hurricos>
I must have missed that, if you think it's achievable
<hurricos>
separate thread?
<mrnuke_>
musl has supported C11 threads since the very early days. No need to depend on libpthread
<hurricos>
*chokes on hard boiled egg* eh??
<hurricos>
But my college prof told me I needed libpthread ;'(
<mrnuke_>
Yeah, I don't like use of threads when a pure async design just work, but the i2c-dev design necessitates threads
<hurricos>
or no, maybe I learned both. I seem to remember that. it's been 6 years
<mrnuke_>
BTW, You may now test and merge PR15. I think I'm satisfies with the result
<hurricos>
Sweet.
<hurricos>
OK, so ... recovering my understanding here
<hurricos>
we create a separate thread whose job it is to provide <a thing> that ubox can poll() from?
<hurricos>
As I think about it it makes less and less sense
<hurricos>
unless we're passing something different to ubox than a fd to the device
<hurricos>
I have libubox cloned down btw
<mrnuke_>
Well, no, you create a thread that consomes from the commands list, and populates the replies list (I know, there is no replies list)
<hurricos>
oof, so we're sort of replacing uloop here
<hurricos>
err, ustream
<mrnuke_>
Generally, when opening a socket, you get to choose between STREAM or SEQPACKET. the UART is a stream that we need to turn into packets. The I2C is a seqpacket already. No point detangling the packets into a stream and re-packetizing it
<mrnuke_>
Dows libubox support SEQPACKET style polling? I don't know -- we may need to get creative
<mrnuke_>
SOCK_SEQPACKET. I2C maps better to SOCK_SEQPACKET. UART maps better to SOCK_STREAM. libubox handles streams just fine. Not sure how we'd do the other
<mrnuke_>
I know they are networking concepts. I'm using them to illustrate the concept, not suggest networking APIs
<hurricos>
I gotcha. As far as I'm reading the only difference between the two is that SEQPACKET is responsible for tracking boundaries
<hurricos>
but tracking boundaries on an always-exactly-12-byte packet protocol is trivial
<hurricos>
Still, your point is taken, we could probably shove the uart-specific `if (len < 12)` into the UART-handling if/when we separate media code
<hurricos>
for example
codedwrench has joined #openwrt-devel
<hurricos>
good reason to get rid of uloop actually
<hurricos>
again, sorry, ustream.
<hurricos>
Because ustream's only job right now is to provide us with replies as they come
<hurricos>
since our i2c read is going to always give us 12B, we're always going to have *a packet*
danitool has joined #openwrt-devel
goliath has joined #openwrt-devel
MaxSoniX has quit [Quit: Konversation terminated!]
codedwrench_ has quit [Remote host closed the connection]
Borromini has quit [Quit: Lost terminal]
danitool has quit [Remote host closed the connection]
<codedwrench>
Hi, has anyone tried to compile boost statically on mipsel_24k , i have been getting linker errors, the .a files are there, but it seems i'm missing symbols? I dont see them either when checking with nm. I have been trying to compile this https://github.com/codedwrench/xlinkhandheldassistant , the output is the following: http://sprunge.us/GX6kyg , the target i'm compiling for is a vocore v2
<hurricos>
In all reality I'm probably going to scurry off and start some PRs adding the MCU to i2c
<hurricos>
s/MCU to i2c/MCU to the i2c bit of the device tree on these boards/
danitool has joined #openwrt-devel
<mrnuke_>
hurricos: I know too little of how libubox works. That's my main concern. Getting the packets from the i2c thread back to the main loop. Right now that's done through ustream_fd -- it gets data from outside into realtek-poe. Not sure how well it supports getting data from realtek-poe to realtek-poe
<mrnuke_>
hurricos: I don't have any spectacular reads on thread safety off the top of my head;. I think the LDD3 chapter on it was pretty good
Tapper has joined #openwrt-devel
matoro_ has joined #openwrt-devel
matoro has quit [Ping timeout: 480 seconds]
computare has joined #openwrt-devel
computare has left #openwrt-devel [#openwrt-devel]
philipp64 has quit [Quit: philipp64]
<hurricos>
argh! I didn't realize I was so effing bad at C.
<mrnuke_>
hurricos: Why do you say you're bad at C. There is a difference between knowing C, and knowing the UNIX concepts, like fd's, poll, and the like
<hurricos>
I think the intertwined concept is "not knowing how to write code without running bits of it". That and not being familiar with the idioms needed to do some of these code-change operations
<hurricos>
like splitting one .c into multiple and having them assemble into one after the fact
<mrnuke_>
I run (incomplete) code as I'm writing it. That's normal!
<hurricos>
hard to do with c :P
<mrnuke_>
bringing several .c files back together is really linker/compiler specific. All you really need to know in C is the linkage -- don't make it static
codedwrench has quit [Remote host closed the connection]
<mrnuke_>
hurricos: BTW, true fact. For the retry logic in #15, I had two ways to do it. They both took the same amount of code. So I asked the gf which one is easier to understand. She doesn't know C, so I trusted her choice exactly because of that
<dwfreed>
rubber ducking
<dwfreed>
with a duck that can speak :D
<mrnuke_>
dwfreed: I feel guilty for finding that funny!!!
<hurricos>
I'll get there. I have the idea on paper for separating the medium init and handling -- uart_stream.c takes the ustream code handling uart, i2c_handle.c (naming?) takes the code that handles i2c; both of them implement the backend for poe_open_medium, poe_cmd_send
<hurricos>
I'm OK with how that breakdown would look (poe_open_medium would check which backend and then call the right helper, poe_cmd_send ...)
<hurricos>
poe_cmd_send is actually where the hangup happens. the i2c implementation always does it immediately, the serial implementation waits for the next state timeout callback before flushing the queue
<hurricos>
the difference is less of a problem than the fact that the state callback comes back from ustream which main.c (on paper) doesn't know or care about
<hurricos>
RE: on paper, my idea on paper, for separating these
<hurricos>
I know it does right now.
<hurricos>
Care.
<hurricos>
I'd like main.c to provide a queue and each uart_stream and i2c_handle read that queue in its own way
<hurricos>
but those need to call back to stuff in main.c
<mrnuke_>
hurricos: You have the common code, and and some point, it needs to call uart/i2c specific code. It's an issue of interface design, right?
<hurricos>
Right, the problem being that right now the interface is not clean
<hurricos>
since uloop and ustream both have callbacks *in* main.c
<mrnuke_>
You could be writing it in AGC assembly, and you'd have the same issue ;)
<hurricos>
In Perl this'd be easy, and sadly I've been doing nothing other than Perl for the last three or so years
<mrnuke_>
Let's see, what's the UART specific code? There's tcsetattr() and tcflush(), that are both part of *stream_open(). Then you have read() and write() syscalls. that's it!
<hurricos>
as well as *_stream_*, however, as those are completely unused by the i2c-specific code or anything else
<mrnuke_>
what _stream_ ?
<hurricos>
e.g. poe_stream_msg_cb
<mrnuke_>
that's a libubox thing.
<hurricos>
Right, but unless I want to hobble the i2c interface by using ustream directly (which will call read()), it's not compatible
<mrnuke_>
Yeah, It's a libubox limitation!
<hurricos>
using ustream forces how the device will be read
<hurricos>
That's fine for serial, it works great. So do you reckon I simply drop that and reimplement what it does ...
<hurricos>
?
<mrnuke_>
I reckon we chase down some libubox experts and ask them how they'd do it
<mrnuke_>
I have very strong feelings towards any piece of software that's not documented
<mrnuke_>
(looking at you, systemfakd)
<hurricos>
oh, that's the other thing
<hurricos>
I've dug through a lot of libubox and seen how it's been implemented, but I don't know how I'd figure out the behavior of its code
<mrnuke_>
The lack of documentation pisses me off too!!!
<mrnuke_>
But, I am careful. I don't want to ask for documentation and get a bunch of doxygen crap that just re-iterates what the code already says reduntantly waht it says
<mrnuke_>
Well, normally, poll(), or epoll(), or select(), will tell you that there are bytes available to read on an FD. That's the magic
<hurricos>
my blocker is, hmm, what do I write to mimick the behavior of this read to compare a read against i2c and a read against serial
<mrnuke_>
I can have a thread sending packets to my loop. Then the loop notifies my code that a packet has arrived. Can I do that without an fd?
<mrnuke_>
if you have an fd, you're going back to the OS. And then it's trivial -- just open a socket to yourself. It's also probably stupid?
<hurricos>
well of course, through a callback, or by adding to some kind of object in shared memory, i.e. atomically lock a list, add to the end of it, release the lock
<hurricos>
don't need an fd
<hurricos>
I guess the lesson learned is I need to stop ignoring my lack of knowledge, and spend some time actually trying to compile the examples spinning around my head to test the behavior of these parts
<russell-->
i'm also seeing a crapton of "... has a build dependency on 'libiconv', which does not exist"
<hurricos>
so that I can move on after understanding how they work
<hurricos>
I got a sinking feeling when I realized musl implemented C11 threads way before glibc though :P
<hurricos>
but no, that's not a good reason, I can pull down a toolchain image and compile under that
<hurricos>
it's just messy
<mrnuke_>
hurricos: I'll you and bkobl out in splitting the code, setting up a thread, locks, and even some ubox stuff
<mrnuke_>
It's just the ubox stuff that's getting in the way
<mrnuke_>
THere's a "help" missing ^^
<hurricos>
ustream is causing problems for sure
* mrnuke_
is looking into ustream vs ustream-fd differences
<mangix>
russell--: rm -rf tmp
<russell-->
Mangix: yep, that fixed it.
<hurricos>
mrnuke_: they aren't exclusive, ustream-fd looks to be for reading from fd, none of the examples show the use of ustream standalone, but it looks to be the parts of ustream not dealing with the file, just handling the buffer for you
<hurricos>
looks like? I'd guess*, rather
<mrnuke_>
hurricos: I'm going to click the "Approve and Run" button on #22. I'm not approving the PR, but I want to give bkobl
<mrnuke_>
's changes a chance to get build-tested
<hurricos>
oh true
<mrnuke_>
I wish I could keep the thing as a sequence of packets, rather than turning it back into a stream. Maybe there's a helper other than ustream we should be looking at
<hurricos>
mrnuke_: If we could tell ustream to wait on sending the callback until we had 12 bytes, that would achieve the same thing
<hurricos>
ultimately ustream doesn't ever actually poll, is the other thing I saw. This becomes a problem iff the behavior of i2c and tty chardevs differs upon read() when bytes aren't availble
<mrnuke_>
We're already doing that (somehow)
<mrnuke_>
hurricos: Hold on a sec. We're opening the UART fd with O_NONBLOCK. What would happen if we opened an i2c FD with the same flag?
<hurricos>
if you're saying poe_stream_msg_cb never hits the `if (len < 12) return;`, then well, then that's because ustream_fd_read_pending only drops out once it's done reading, and the mcu consistently sends out one packet at a time
<hurricos>
if you're not saying that, I'm guessing you weren't thinking of that line in poe_stream_msg_cb
<mrnuke_>
I'm not saying it doesn't hit it. I'm saying that's how we're packetizing. (Which has its own set of problems that I won;t go into)
<hurricos>
I'd love to say, but I haven't figured out how to get an i2c dummy driver set up so I can test on my laptop, nor have I found an i2c-based mcu
<hurricos>
in an implementation that has OpenWrt on it, though I might not be paying enough attention to the openwrt/openwrt PRs
<hurricos>
read as no hardware to test on to find out
<hurricos>
RE: O_NONBLOCK
<mrnuke_>
umh, do you have any openwrt device with an i2c slave? You might be able to try it there. Try i2cdetect from i2c-tools to find out
<hurricos>
What's nasty about this is that we're abusing undocuemnted / unstated behavior in ustream
<hurricos>
I have an MX60 which has a not-bound-by-driver clock generator as a slave
<mrnuke_>
We were already using undocumented ustream functionality. It's by definition. None of it is documented
<hurricos>
lol
<hurricos>
touche :^D
<stintel>
greetings from Istria, Croatia :)
<Habbie>
hello!
<hurricos>
Are there any clever non-C ways to open FDs with speicifc options?
<mrnuke_>
Cool, so if you want to play around with the flags, just do that, and use a monotonic clock to see if the transaction is blocking or not
<mrnuke_>
hurricos: open() is not really C. It's a UNIX syscall. Happens to be implemented in C.
<hurricos>
I know, digging into ash documentation to see if exec lets you mess with flags
<mrnuke_>
On an fd that is unique to the process running it? How would that help?
<hurricos>
oh, though ash's fd opening implementation is probably not clean enough for me to see myself in it
<mrnuke_>
You can try python. I think the sys module has a way to do FD's
<hurricos>
if I can exec 3>/dev/i2c-0 with flags, that's open
<hurricos>
464fp = no python :^)
<hurricos>
:crying"
<hurricos>
I'll find a better device, they exist.
<mrnuke_>
A beaglebone black or crapsberrypi?
<hurricos>
I'm wrong! it has python3. Must have been broken last I tried
<hurricos>
and I also forgot perl has it and will be much more kosher, too. OK, time to go for an adventure :')
<mrnuke_>
👍
Misanthropos has quit [Ping timeout: 480 seconds]
Misanthropos has joined #openwrt-devel
PaulFertser has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
<hurricos>
this is miserable.
<hurricos>
It's all undocumented!
<hurricos>
The kernel i2c-dev documentation doesn't clearly delineate the differce between ioctl'ing device's address, and then specifying (in a READ) which memory addresses ON that device you'd like to read
<hurricos>
i2c-get works fine thankfully :P
<hurricos>
so at least I have something to compare to.
PaulFertser has joined #openwrt-devel
<hurricos>
Heck yeah, it works!
<hurricos>
mrnuke_: O_NONBLOCK makes no difference
<mrnuke_>
Hmm, I was afraid so
<hurricos>
well, it reads the i2c device either way
<hurricos>
in this case, the i2c device is a clock generator which isn't meant to report back anything
<mrnuke_>
I was checking linux sources. i2c does not check the f_flags field (which would contain O_NONBLOCK)
<hurricos>
i2c-dev in this case
<mrnuke_>
Is the call on the order of milliseconds?
<mrnuke_>
*the execution time of the (read() or write()) syscall
<hurricos>
30-50ms, though I can time the exact read
<mrnuke_>
Yup, that's definitely blocking. I'd expect a non-blocking call to be on the order of nanoseconds
Tapper has joined #openwrt-devel
<hurricos>
How, exactly?
<hurricos>
the i2c transaction must occur between the read and the response.
dlg_ is now known as dlg
<hurricos>
i2c relies on a fairly slow clock
<hurricos>
I haven't timed the call itself here
<hurricos>
really, I'm trying to get a sense of when returning immediately is desirable
<hurricos>
we want blocking if it can happen in a separate thread and if that thread has a way to notify us that we have work to do once blocking completes
<hurricos>
we don't want blocking if it's in the main thread. But what would we do with a non-blocking read() anyways? We'd have to spin for a response in either case
<hurricos>
I think I've been looking at this for too long and I'm no longer understanding any of it.
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
<mrnuke_>
hurricos: Good. That's exactly how I approach C. When I no longer understand it, submit pull request :p
<hurricos>
lol.
<hurricos>
To that point, when the hell does ustream-fd even *run*?
<hurricos>
I can't find a scheduler loop at all.
<hurricos>
It'd make sense if it's running read and getting eof.
<mrnuke_>
It's registering its fd with epoll(), and runs whenever the kernel says there's an event
<hurricos>
(until the hardware actually suddenly gives it something it wants.)
<hurricos>
epoll ...
<mrnuke_>
I think code is in uloop-epoll.
<hurricos>
care to show me where? I see only uloop referencds
<hurricos>
My question is, re: ustream: either our use of ustream causes a separate thread to be created -- even if C11 threads are lwp's! That is, I realize I may not bge able to verify this with top, and without strace et al! -- or we're fucked, becuase epoll *blocks*
<hurricos>
poll is blocking, that's its whole point. it just doesn't do so in a way that is painful
<hurricos>
poll returns to the program once it's achieved something
<hurricos>
so why are we litigating this at all, if that's what a blocking read does?!
<mrnuke_>
poll() returns once an event has occurred, and there is something for the program to do
<hurricos>
or I've fundamentally misunderstood epoll and it gives you threaded behavior from nowhere
<hurricos>
right
<hurricos>
read: blocking
<hurricos>
I've requested something, it'll get back to me but block until then
<mrnuke_>
yeah, a packet comes in, or a ubus request comes in, epoll() wakes you and sends you on your merry way
<hurricos>
if our ustream setup is creating a thread, and that *thread* gets blocked on uloop-epoll's epoll_wait ... then where is ustream setup threaded?
<mrnuke_>
There's no thread created by epoll
<hurricos>
On the other hand, maybe I'm wrong, and the whole control process is in uloop and I bow to how it's doing scheduling but admit it's too much to read
<hurricos>
I just don't understand how it's managing blocking. epoll_wait runs. oh
<hurricos>
oh fuck
<hurricos>
I see it now
<hurricos>
epoll_wait points to ALL THE THINGS realtek-poe cares about
<mrnuke_>
uloop is not scheduling anything. The kernel tells you event occured on this fd, then uloop runs the callback registered with that fd.
<hurricos>
return from fd? check. ubus? check
<hurricos>
gahhhhhhhhhhhhhhhhhhhhhhhhhh
<hurricos>
OK, I kept reading "from multiple fd's" in the description of poll / epoll / etc. and thinking "that must be important"
<hurricos>
but not realizing why
<mrnuke_>
Haha! sure!
<mrnuke_>
Yeah. So a blocking read() or ioctl() preventes epoll() from waking you up and sending you to process whatever needs to be processed.
<hurricos>
so we sit in uloop_fetch_events, and on the uart side we do, yes, indeed, register a ustream to add to the things epoll_wait waits on.
<hurricos>
if only we had a ustream that was packet specific ...
<hurricos>
ustream-packet.
<hurricos>
but adding to undocumented mess = bad time
<jow>
the whole purpose of ustream is to provide a somewhat stream-like interface on top of sockets
<hurricos>
ok, so it's at this point that I find my usb keyboard so I can actually page down on the list of logged in users and
<hurricos>
hey jow :D
<jow>
if you only exchange fixed packet size data chunks it adds nothing but complexity
<hurricos>
now I can skip finding the keyboard
<jow>
drop it
<mrnuke_>
hi jow! I like your advice :)
<hurricos>
Neat :D
<jow>
register a plain socket fd with uloop
<hurricos>
OK, so .... uloop is going to continue to run. I wonder if there's any way ...
<hurricos>
how?!
<jow>
when you get a read event notification, do a pleain read(fd, buf, 12)
<hurricos>
that's what we need, we still care about uloop managing it
<hurricos>
what do we register with uloop here?
<jow>
maybe do the required EAGAIN / EINTR nonblock IO repeat bilerplate around
<jow>
struct my_stuff { struct uloop_fd ufd; other stuff };
<jow>
my_stuff->ufd.fd = socket(...); // or open() or whatever you gyus do there
<jow>
my_stuff->...; // init other stuff you might need
<jow>
my_stuff->ufd.cb = my_read_callback;
<jow>
uloop_fd_add(&my_stuff->ufd, ULOOP_READ);
<jow>
in your callback:
<jow>
struct my_stuff *blah = container_off(ufd /* the uloop_fd pointer you get as 1st arg in the callback */, struct my_stuff, ufd);
<jow>
*container_of()
<mrnuke_>
jow: The root cause of our issue is that we need to integrate some I2C traffic into events processed by uloop. I2C syscalls are blocking, and we're considering doing I2C calls in a seperate thread, then pushing the data back to uloop
<hurricos>
jow: know a quick way to test whether a given file can be poll()'d?
<jow>
and then access blah->ufd.fd to get the low level unix fd
<jow>
if you don't need additional context you can also work with ufd directly, without container_of(): int fd = ufd->fd;
<hurricos>
we've assumed i2c cannot be; if it can using this more or less verbatim should work; if not, feeding a uloop_fd is the only way we could continue to use uloop here
<hurricos>
i2c-dev*
<jow>
mrnuke_: OpenWrt u* libs and pthreads don't mix well
<jow>
hurricos: so i2c is no simple read()/write() interface on top of FDs?
<jow>
mrnuke_: that's just sugar coating on top of pthreads
* mrnuke_
checks
<jow>
at least the linux side musl and glibc implementations
<jow>
hurricos: what kind of IO streams are involved? why is the blocking ioctl) a problem?
<jow>
what kind of IO must be (potentially) served while ioctl() blocks?
<f00b4r0>
mrnuke_: except most implementations are in fact using pthreads behind the scenes
<f00b4r0>
oh, jow already mentioned that :)
<mrnuke_>
jow: Umh, just checked. ldd <binary> doesn't show linkage to pthreads
<jow>
mrnuke_: because musl has no separate libpthread.so
<jow>
it's all part of libc.so
<mrnuke_>
jow: that's what I want. No extra library dependency
<jow>
gtg, will be back later
<hurricos>
jow: i.e. ubus call's
<f00b4r0>
i had a piece of code written with c11threads support. When I realized that it was less portable than pthreads and offered no benefits, I was quick to scrap the whole thing and go back to pthreads.h
<hurricos>
not a problem if we're using a uloop_fd (requires us to be able to poll)
<hurricos>
mrnuke: yeah, yeah, I know, I get it. I have to do some real-life stuff but I'll test it out :P
<hurricos>
confirmed that i2c-dev is smart enough to not seek after reading. I realize this is probably the default
<hurricos>
oh wait
<hurricos>
no that's a chardev v blockdev thing
<hurricos>
thanks, man 2 read
<mrnuke_>
hurricos: what if, the i2c thread just calls poe_reply_consume() almost verbatim, and we just add some locking
<mrnuke_>
?
<mrnuke_>
UART code stays mostlyt the same
<mrnuke_>
UART code also needs to packetize and call ustream_consume(). I2c does not
<hurricos>
no point having a thread if uloop can callback when there's something to read, unless of course there's something nightmarish in reading that file, which I expect there will be
<mrnuke_>
that nightmarish thing is that readind i2c-%d is blocking
<hurricos>
No, the nightmarish thing would be reading a packet does not then cause the i2c device to block completely on next read
<hurricos>
uloop's epoll_wait lets it sit reading and blocking forever otherwise
<hurricos>
which is exactly what we want
<hurricos>
to only act upon the next packet if there is a next packet
<hurricos>
given all of our code is managed by uloop right now I can't see a bad thing, no locking needed
<mrnuke_>
Well, no. on UART, you call write(), buffer the data, and go back to epoll_wait(). That takes nanoseconds.
<hurricos>
I'm gonna merge 15, then convert our uart loop into uloop instead of ustream
<mrnuke_>
with i2c ioctl(), you don't go back to epoll_wait() until after all the bytes have been sent and received
<hurricos>
we're not using an ioctl, we'll just plain read+write
<mrnuke_>
same thing.
<mrnuke_>
i2c read() write() calls are blocking, just like the ioctl
<hurricos>
I don't think writing takes time
<hurricos>
haven't tested, in this case I can't actually test because the i2c device is a clock generator running the pcie card :D
<hurricos>
I can test on a less consequential device
<mrnuke_>
calls i2c_master_send(), which calls i2c_transfer(). Same shit as the IOCTL, different name
<hurricos>
gah
<hurricos>
we could try to register one fd for writing and one for reading
<hurricos>
oh! that's it
<hurricos>
use epoll both ways
<hurricos>
and have (as you were looking for) one cmd queue and one reply queue
<hurricos>
well, no. Because epoll isn't writing for you. Hmm.
<mrnuke_>
And how exactly would that solve the blocking problem?
Tapper has quit [Quit: Tapper]
<hurricos>
right, I got it, there's no buffer. epoll is helpful when writing because you're writing to your hardware buffer. No such buffer, hardware (doesn't exist) or software (through kernel binding a driver to that i2c endpoint) has turned up
<mrnuke_>
I'm thinking, like jow said, take uloop out of the picture for i2c, leave it for uart. Design the transport/medium interface to account for this
<hurricos>
so that's what we're really implementing here with a separate thread, a software buffer for reading and writing.
<hurricos>
well, uloop is everything
<hurricos>
we'd need two programs with almost no common flow
<hurricos>
uloop is also watching ubus for us
<hurricos>
the separate thread could be doing all of the i2c reading and writing but then we have to have locks on pretty much everything. limit the separate thread to just reading and writing and we're OK, but at
<hurricos>
oh
<hurricos>
so for reading i2c is supposed to have a data ready bit
<hurricos>
Let me test reading of only one byte here
<hurricos>
huh
<hurricos>
Perl is not testing this adequately, but reading one byte is extremely fast
<hurricos>
fast enough that checking the date takes much longer than anything else
<hurricos>
reading all 0x80 takes much longer
<hurricos>
on the order of 10ms
<hurricos>
300 microseconds
<hurricos>
for one byte
<hurricos>
15ms for 80
<hurricos>
0x80* (128)
<hurricos>
0x80* (128)
<hurricos>
seems to scale in-between. Are we that worried about 300us of blocking?
<hurricos>
I know that the full ioctl that does the read and write will take much longer, bkobl's comments demonstrate that
<hurricos>
but we're not waiting on the full ioctl, we're just writing and then letting epoll tell us when we can read
<hurricos>
this doesn't account for the possibility I mentioned btw
<hurricos>
so we still have to contend with the fact that epoll may respond to us nevertheless
<hurricos>
but we might survive that if there's a data-ready bit we can proxy instead
<mrnuke_>
what are you running your I2C bus speed-wise?
<mrnuke_>
umh, how does epoll know you want to initiate an i2c read transaction?
<hurricos>
The same way it ordinarily knows
<hurricos>
mrnuke_ let me check the device tree on the mx60.
<hurricos>
mrnuke_ when we pass epoll_wait a bunch of fd's, it figures out which ones are going to have data for us
<hurricos>
the problem (maybe this is your point) is that i2c doesn't care. The readable address space is going to have stuff for you at all times if you wait
<mrnuke_>
so, epoll will willie-nillies initiaite i2c-reads for us?
<hurricos>
yeah, which isn't going to help as i2c always has data :P
<hurricos>
even if there were an i2c ready bit epoll isn't designed to watch for it to change
<mrnuke_>
of the _exact_ size we need?
<hurricos>
If the fd actually blocked appropriately, the response would always be 12 bytes
<hurricos>
we're not buffering anything here, the data is always there to be read, but we need to initiate it
<hurricos>
you have pointed out the problem obviously, we have no indicator to know that the data we're going to read from those 12 bytes is ready
<hurricos>
unless, well, the mcu might not service i2c requests until it's done actually transacting its stuff
<mrnuke_>
Initiating the transfer is a blocking read with i2c-dev. No way around it
<hurricos>
which is what bkobl's code relies on in using I2C_RDWR
<mrnuke_>
But don't believe me. Look into i2c-dev.c . Notice all the copy_to_user() calls after a read transfer ?
<hurricos>
if reading one byte takes 300us I'm not worried aboutit
<hurricos>
I do believe you
<hurricos>
there's no hardware buffer anywhere to make that not the case, it's a master/slave interface and our silicon doesn't do any buffering for us (though there are some that can)
<hurricos>
I don't see a frequency but it's a ibm,iic-460ex compatible, and I see a line in /proc/interrupts for it, so there might be some hardware my board has that realtek does not
<hurricos>
mrnuke: 100KHz / 400KHz
<hurricos>
IMO the only way to know the performace of this is going to be to test it
<hurricos>
I won't have OpenWrt hardware that can test it until it gets ported
<hurricos>
∴, let's shelve this until that is true
<hurricos>
seems like too much speculation for no gain
<hurricos>
I'm marking #22 a draft for that purpose
<mrnuke_>
Okat to tableing #22 for now
<mrnuke_>
hurricos: we can take a supported switch, solder wires to an unsupported switch, and test things that way, right? :p
<mrnuke_>
(I'm just joking. Don't actually do that)
<hurricos>
horrible.
cmonroe has quit [Read error: Connection reset by peer]