<larsc>
better quite before it stares back into you?
<whitequark>
larsc: yes.
* whitequark
shudders at the very thought of 7.3MLOC of GCC staring at him.
<larsc>
:)
<whitequark>
there is something Lovecraftian about that. an ancient beast waking up from its eternal dream, only to cast a single stare and drive an innocent programmer on the verge of insanity
xiangfu has joined #qi-hardware
rz2k has joined #qi-hardware
<wpwrak>
see, better hurry and lose your innocence. then you're safe :)
<whitequark>
I wonder what would constitute losing innocence in the context of GCC...
erikkugel has quit [Read error: Connection reset by peer]
erikkugel has joined #qi-hardware
pcercuei has joined #qi-hardware
<whitequark>
omg.
<whitequark>
a polite postal worker (!) who, having seen an attached paper which stated a weight difference (0.9kg vs 0.6kg) asked me to check the contents and said she'll help with paperwork if something's actually was missing
<whitequark>
(!!)
<pcercuei>
there are some nice people out there :)
<wpwrak>
s/polite/fake/ ? :)
<whitequark>
wpwrak: haha
<whitequark>
also they did not lost the parcel despite me writing the wrong zipcode
<larsc>
whitequark: you'll be on one of these hidden camera shows
<whitequark>
and, in a previous encounter with EMS (a subsidiary of the russian post), when I've had two parcels to receive and forgot to write the flat # on one of them, a courier who delivered the second one has remembered it and offered to redeliver
<whitequark>
I wonder if they're they still a government-sponsored organization?
<wpwrak>
larsc: he should go easy on these mind-altering drugs, particularly the strong ones
LunaVorax has quit [Ping timeout: 256 seconds]
LunaVorax has joined #qi-hardware
mth has quit [Ping timeout: 248 seconds]
mth has joined #qi-hardware
LunaVorax has quit [Ping timeout: 256 seconds]
Calyp has joined #qi-hardware
xiangfu has quit [Quit: leaving]
LunaVorax has joined #qi-hardware
panda|x201 has joined #qi-hardware
<whitequark>
huh, 2/3 of connections are suddenly ECONNREFUSED. not sure if just crappy connection or malfunctioning censorship engine
<whitequark>
regardless, openvpn solves this :)
Calyp has quit [Read error: Connection reset by peer]
Calyp has joined #qi-hardware
LunaVorax has quit [Ping timeout: 256 seconds]
wej has quit [Ping timeout: 245 seconds]
panda|x201 has quit [Ping timeout: 260 seconds]
jluis has quit [Ping timeout: 245 seconds]
wej has joined #qi-hardware
LunaVorax has joined #qi-hardware
pcercuei_ has joined #qi-hardware
kyak has quit [Read error: Connection reset by peer]
pcercuei has quit [Ping timeout: 252 seconds]
kyak has joined #qi-hardware
kyak has quit [Changing host]
kyak has joined #qi-hardware
emeb has joined #qi-hardware
<viric>
meh
<viric>
UBI error: ubi_read_volume_table: the layout volume was not found
LunaVorax has quit [Ping timeout: 256 seconds]
<viric>
oh the new qemu added a NAND to the default mips board
<viric>
Creating 3 MTD partitions on "physmap-flash.0":
<kyak>
wpwrak: spi-gpio-atben and spi_atben_gpio - i'm already lost :)
<kyak>
btw is there a naming convention for kernel modules at all?
LunaVorax has quit [Ping timeout: 256 seconds]
<larsc>
for some
<larsc>
e.g. some subsystems use a common prefix
<larsc>
like i2c-foobar
<wpwrak>
kyak: yeah, it's a little messy :) also, spi_atben is somewhat correct because it implements a SPI driver, but then spi_atben_gpio only puts things together
<wpwrak>
kyak: but i think spi_atben can die now. it was the very first one i wrote.
<wpwrak>
and spi_atben_gpio needs a less confusing name
<wpwrak>
spi-* are all real SPI drivers
<kyak>
is there a chance atben and atusb drivers will be accepted by upstream?
<kyak>
is it even something you want to do, or we don't really care?
lekernel has joined #qi-hardware
<wpwrak>
oh, i want them upstream. i don't expect undue difficulties. just need a bit more testing.
<wpwrak>
and atben has a bunch of at86rf230.c fixes it semi-depends on as well (as in "i already know it'll crash and burn before long if they're not there"). they sould probably go in first.
<kyak>
cool :)
<wpwrak>
of course, atben has the added issue that some things are missing in mainline for proper ben support. i do my development on a board without lcd, so i just applied the two patches i need to get at least that far. but that kernel probably has no lcd. and it also doesn't have USB.
<wpwrak>
(i flash directly via usb-boot, which is very easy if you have idbg)
<wpwrak>
(and can of course be the mother of all nightmares if you don't :)
<kyak>
do you mean that your driver might affect USB?
<wpwrak>
no, but the net-next kernel doesn't have the patch for the jz4740's USB device. so anything you build from that source will be a somewhat limited ben.
<wpwrak>
not sure where that driver is in the pipeline, if it's on the way into mainline at all
<kyak>
ok, now i understood :)
<kyak>
though i thought that most of the patches went upstream
<kyak>
except for partitions maybe
<wpwrak>
maybe it's somewhere in a tree that hasn't been merged yet. we have quite a number of patches in the qi-gw owrt repository that aren't in mainline. e.g., several NAND performance improvements.
LunaVorax has joined #qi-hardware
lekernel has quit [Quit: Leaving]
<pcercuei>
hmm
<pcercuei>
how can I stop a blocking read() call from a different thread?
<larsc>
kill the thread
<larsc>
or send any other signal
<pcercuei>
well, I tried that :)
<pcercuei>
pthread_kill(thd, SIGTERM)
<pcercuei>
doesn't stop the read() call :(
<larsc>
it should, at least if the signal is not blocked
<pcercuei>
well, SIGTERM should never be blocked, no?
<larsc>
SIGKILL is unblockable
<larsc>
SIGTERM is just like any other signal
<pcercuei>
hmmm
<pcercuei>
ok
<larsc>
it's also possible that your backend does a non-interruptible sleep
<pcercuei>
so I believe I just have to use sigaction()?
<larsc>
probably
<larsc>
or you just use poll and friends
<pcercuei>
polling would be a bit... dirty
<larsc>
no, poll()
<larsc>
a.k.a select()
<pcercuei>
larsc: sigaction() does affect the whole process, not only a thread
<viric>
pcercuei: I think you can close the fd
<pcercuei>
viric: oh, good idea
<pcercuei>
that would probably work
<pcercuei>
viric: doesn't work :(
<pcercuei>
calling close() on the file descriptor doesn't stop the read()
<larsc>
what are you reading on?
<pcercuei>
a file descriptor obtained with inotify_init()
<viric>
hm ok
<viric>
then I'm with lars
<viric>
select or signal
<larsc>
according to the code inotify_read is interruptible
<pcercuei>
that's why I don't understand why I can't interrupt it ;)
<viric>
interruptible means that on a signal it will unblock, no?
<viric>
maybe you have set SA_RESTART for SIGTERM ?
<pcercuei>
well, my code doesn't set it
<viric>
ok
<viric>
I never understood how threads and signals cope together though
unclouded has joined #qi-hardware
rz2k has quit []
<larsc>
wpwrak: be careful if you ever want to buy a poodle