2010-11-09 00:01 <tidux> does anyone know if/when the next round of SIEs is coming out?
2010-11-09 00:06 <wolfspraul> he
2010-11-09 00:07 <wolfspraul> tidux: from my side: as soon as someone orders :-)
2010-11-09 00:07 <wolfspraul> the plan was this: the last run was V2, and (that's a good thing) as part of the V2 run we realized several bugs/shortcomings
2010-11-09 00:07 <wolfspraul> so work started on a V3 to address those errata
2010-11-09 00:07 <wolfspraul> I'm able and willing to manufacture more, and I have a lot of parts in stock already
2010-11-09 00:08 <wolfspraul> I can either manufacture V2 or V3
2010-11-09 00:08 <wolfspraul> but, now to the problems..
2010-11-09 00:08 <wolfspraul> I do not recommend making more V2, see the bugs we found
2010-11-09 00:08 <wolfspraul> the yield was also not good, if I would do another V2 run I would factor the yield into the price in advance
2010-11-09 00:08 <wolfspraul> I need an order of at least 200 or so
2010-11-09 00:08 <wolfspraul> better would be to go to V3, but I am not sure whether it is 100% finished and reviewed yet
2010-11-09 00:09 <wolfspraul> also for V3, I need a minimum order of maybe 200 or so
2010-11-09 00:09 <wolfspraul> tidux: the guy who is working on this is tuxbrain_away
2010-11-09 00:09 <tidux> cool
2010-11-09 00:09 <tidux> sorry, I was afk for a bit
2010-11-09 00:09 <wolfspraul> tidux: are you asking about 1 unit for yourself, or a bigger order?
2010-11-09 00:09 <tidux> 1
2010-11-09 00:09 <wolfspraul> if you just want 1 unit, you need to talk to tuxbrain_away, maybe he is having some sort of preorder/registration list
2010-11-09 00:09 <wolfspraul> don't know
2010-11-09 00:09 <tidux> ok
2010-11-09 00:10 <wolfspraul> I'm ready to make more
2010-11-09 00:10 <wolfspraul> but I cannot make 1
2010-11-09 00:10 <wolfspraul> unless you pay a few thousand USD for it
2010-11-09 00:10 <tidux> I understand
2010-11-09 00:10 <wolfspraul> and I suggest we apply what we learnt in V2 first, and make a nice step to a better V3
2010-11-09 00:10 <tidux> no, that's totally cool
2010-11-09 00:12 <tidux> alas, gentlemen, I must retire for the evening
2010-11-09 05:45 <rafa> mornint
2010-11-09 05:45 <rafa> morning
2010-11-09 05:47 <kyak> moarning
2010-11-09 05:50 <wpwrak> yawn :_
2010-11-09 05:50 <drizzt> lol
2010-11-09 05:50 <drizzt> big yawn in my case
2010-11-09 05:51 <wpwrak> busy night ? :)
2010-11-09 05:56 <drizzt> yes
2010-11-09 05:56 <drizzt> got to bed at 3am
2010-11-09 05:56 <drizzt> I just read your answer
2010-11-09 05:57 <drizzt> there is in fact reference designs
2010-11-09 05:58 <drizzt> for example : http://focus.ti.com/docs/toolsw/folders/print/tmdxevm8168ddr2.html
2010-11-09 05:58 <drizzt> this one is for the AM389x processor
2010-11-09 05:59 <drizzt> for the case/mechanical parts, I already have someone :)
2010-11-09 05:59 <drizzt> my brother in law in fact
2010-11-09 06:01 <drizzt> he's just started a business with his brother : http://www.lan-gear.com/langear-home
2010-11-09 06:03 <wpwrak> (evb) hmm, no documentation. and no mention of design files.
2010-11-09 06:03 <wpwrak> (mech) excellent ! that helps :)
2010-11-09 06:04 <wpwrak> (evb) it's actually even a bit more expensive that i had thought. but okay, EVBs prices are more or less arbitrary.
2010-11-09 06:04 <drizzt> yep
2010-11-09 06:05 <drizzt> evb documentation is listed under Feature -> software
2010-11-09 06:05 <drizzt> AM389x and C6A816x Software Development kits provided via included 8GB SD Card
2010-11-09 06:05 <drizzt> Documentation
2010-11-09 06:05 <drizzt> 8168 EVM Quick Start Guide
2010-11-09 06:05 <drizzt> 8168 EVM Hardware Users Guide (SD card)
2010-11-09 06:05 <drizzt> ...
2010-11-09 06:06 <wpwrak> that's just a user's manual
2010-11-09 06:06 <wpwrak> not schematics, layout, etc.
2010-11-09 06:07 <drizzt> hum.. I do not know how they got them, but we are actually working on a Davinci processor (TI) with a evb from spectrum digital, and i have all this stuff
2010-11-09 06:08 <drizzt> (and no direct NDA with TI or spectrum digital)
2010-11-09 06:08 <wpwrak> okay :)
2010-11-09 06:09 <wpwrak> schematics are usually included with evbs. that's why i was surprised they didn't mention it. layouts usually not, though.
2010-11-09 06:12 <drizzt> The evb I had (I now have the prototypes) : http://focus.ti.com/docs/toolsw/folders/print/tmdsevm6446.html
2010-11-09 06:13 <wpwrak> but what do you actually expect to need all this processing power for ? most of the time, this device should do pretty much nothing. maybe chat with the sensors once a minute. process an event or two. the big moment would be then the user presses a soft-button. then you'd have to animate it. a sinclair zx81 could probably do it ;-)
2010-11-09 06:13 <drizzt> it's even more expensive than the new one !
2010-11-09 06:13 <wpwrak> whoopie ! must be very low volume :)
2010-11-09 06:14 <drizzt> wpwrak: that for a use limited to domotics control
2010-11-09 06:14 <drizzt> (wich could be done by anything, in fact)
2010-11-09 06:14 <wpwrak> for watching tv, you have a big screen elsewhere :)
2010-11-09 06:15 <drizzt> but the goal is to provide a tablet as well
2010-11-09 06:15 <drizzt> for anything the community would think of
2010-11-09 06:15 <wpwrak> hmm, how would that work ? i thought this device was the domotics controller ? so it may have cables connecting to power line/comms network. not very convenient for a tablet.
2010-11-09 06:15 <drizzt> we already have a few other aplications for it in mind
2010-11-09 06:16 <drizzt> yep, depends on the intended use
2010-11-09 06:16 <drizzt> there are many many use cases
2010-11-09 06:17 <wpwrak> but a the others would be completely different classes of devices
2010-11-09 06:17 <drizzt> some allowing for wired protocols, some not
2010-11-09 06:17 <wpwrak> if you want to compete with the iPad, that's a different story :)
2010-11-09 06:17 <drizzt> lol
2010-11-09 06:17 <drizzt> not compete with, but yes, that's part of the idea
2010-11-09 06:21 <wpwrak> sigh. whatever apple does, one year later, everyone wants to do it too.
2010-11-09 06:22 <wpwrak> in a way, that's nice, though. so all the competition crowds in that year's fashionable corner, fights their patente wars, etc., and leaves plenty of niches for the rest of us :)
2010-11-09 06:27 <wpwrak> i like wolfgnag's approach for the ben. take things that are simple. fully commodized. large parts of the design proven and r&d already written off. that way, you can focus your resources on what makes you different, not waste them in the struggle to stay at the bleeding edge.
2010-11-09 06:29 <wpwrak> also leaves more room to play with the really outlandish ideas, like milkymist ;-)
2010-11-09 06:30 <wpwrak> anyway, let's see what he thinks about that tablet
2010-11-09 07:26 <wpwrak> rafa: btw, will you also upload the respective source packages ?
2010-11-09 07:26 <wpwrak> rafa: (makes things much easier for gpl compliance and such)
2010-11-09 07:30 <rafa> wpwrak: just for extra packages.. (few ones < 10) The rest is the repo built from OE without modifications. If some user wants to get the source he could read the metadata of the package which has a "Source : http://..."  field.
2010-11-09 07:31 <rafa> get the source=get the source of a specific package
2010-11-09 07:32 <wpwrak> ah, i see. i guess that's alright.
2010-11-09 07:33 <rafa> wpwrak: but if we need to host every source code I can upload them :) .. The OE building thing used 100GB+ and a bit part of that were the sources
2010-11-09 07:33 <rafa> bit=big!
2010-11-09 07:33 <wpwrak> disks are cheap ;-))
2010-11-09 07:36 <rafa> wpwrak: for example.. if you check the metadata of bash package downloaded from jlime or soon from qi :
2010-11-09 07:36 <rafa>  wget http://jlime.com/downloads/repository/muffinman/ipk/mipsel/bash_3.2-r8_mipsel.ipk
2010-11-09 07:37 <rafa>  dpkg -I bash_3.2-r8_mipsel.ipk | grep Source:
2010-11-09 07:37 <rafa>  Source: ftp://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz file://builtins.patch;patch=1 http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-001;patch=1;pnum=0 http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-002;patch=1;pnum=0 http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-003;patch=1;pnum.....continues..
2010-11-09 07:41 <rafa> wpwrak: but I am okey with both things.. if we need to uploaded the sources then I will
2010-11-09 07:42 <rafa> wpwrak: about disks are cheap : http://www.happypenguin.org/ (it is the web site of the company making/selling propietary linux games)
2010-11-09 07:43 <rafa> company=linux game publishing company
2010-11-09 07:43 <rafa> "The Western Digital Caviar Green 2TB drive that failed has chemical degredation on the surface making the data recovery much slower and harder"
2010-11-09 07:45 <wpwrak> rafa: nice :) and despite having a backup system
2010-11-09 07:48 <rafa> wpwrak: I was thinking to talk with them to ask if they need people/developers (they use a lot sdl and opengl for everything).. No now it seems :P
2010-11-09 07:50 <wpwrak> right now they need data restoration experts :)
2010-11-09 08:02 <wolfspraul> rafa: I added your pubkey to the www-data and root accounts on turandot.qi-hardware.com
2010-11-09 08:02 <wolfspraul> if you are not sure what you are doing, I suggest to use the www-data account first
2010-11-09 08:02 <wolfspraul> you can definitely copy files into the downloads.qi-hardware.com root folder with it
2010-11-09 08:02 <wolfspraul> /srv/www/downloads.qi-hardware.com in the local filesystem
2010-11-09 08:04 <rafa> wolfspraul: which will be the final link?.. for example.. if, for example, I make a directory named "jlime" (/srv/www/downloads.qi-hardware.com/jlime/). Will it be http://downloads.qi-hardware.com/jlime/ for web browsers ?
2010-11-09 08:04 <rafa> wolfspraul: BTW, thanks for the info and pubkey work
2010-11-09 08:05 <wolfspraul> yes I think so
2010-11-09 08:05 <wolfspraul> the problem is that we have a similar downloads.qi-hardware.com/openwrt url, but that is for sources only
2010-11-09 08:06 <wolfspraul> I have no problem with that, so if it doesn't bother you then just use a /jlime folder
2010-11-09 08:06 <wolfspraul> then /openwrt will be sources, but /jlime will be binaries
2010-11-09 08:06 <rafa> wolfspraul: ah.. great.. Let me work and I will tell you if I feel confident that all is okey (rights, copy, etc).
2010-11-09 08:07 <wolfspraul> rafa: ah wait. wrong!
2010-11-09 08:07 <wolfspraul> the openwrt source location is just called /sources
2010-11-09 08:07 <wolfspraul> downloads.qi-hardware.com/sources
2010-11-09 08:07 <rafa> wolfspraul: for me is okey.. If you have a better idea for names please tell me :)
2010-11-09 08:07 <wolfspraul> well, just make a /jlime and put whatever you like in there
2010-11-09 08:07 <wolfspraul> no I don't
2010-11-09 08:07 <rafa> wolfspraul: okey, I will
2010-11-09 08:07 <wolfspraul>  /jlime is good
2010-11-09 08:07 <wolfspraul> just please keep all mp3 and h.264/mpeg4 stuff out
2010-11-09 08:08 <wolfspraul> that's my only concern :-)
2010-11-09 08:08 <rafa> yes.. /jlime is okey for me as well. so we can have /jlime/images/ and /jlime/repository/ for example.
2010-11-09 08:08 <rafa> wolfspraul: Yes, I am doing my best about shit packages
2010-11-09 08:08 <rafa> ;)
2010-11-09 08:11 <rafa> wpwrak: wolfspraul : tuxbrain_away : In order to have a bit of documentation about the "removed" items: http://fz.hobby-site.org/hp660lx/nn/README_problematic_packages_removed.txt
2010-11-09 08:12 <rafa> wpwrak: wolfspraul : tuxbrain_away : I am going to check the files that every package contains.. trying to find if some package has mp3 or mp4 inside, or similar. I think that because it is a repo built from OE there is not packages with those file formats
2010-11-09 08:12 <rafa> but I want to be sure
2010-11-09 08:13 <wolfspraul> great
2010-11-09 08:15 <wpwrak> rafa: excellent, thanks !
2010-11-09 08:15 <wpwrak> btw, what is "db" ?
2010-11-09 08:16 <wpwrak> sounds like the berkeley database, but that wouldn't be a problem package
2010-11-09 08:17 <rafa> wpwrak: yes, that is berkely database.. and I did not remove that finally ;) I checked every package, why it is there in the README file yet :)
2010-11-09 08:17 <rafa> wpwrak: my grep found that because this is a Oracle product
2010-11-09 08:18 <rafa> why=I do not why
2010-11-09 08:18 <wpwrak> aah :) well, oracle per se isn't evil ... even if they lately try hard to look that way :)
2010-11-09 08:19 <rafa> wpwrak: the idea was to find if there is a "Oracle's java"
2010-11-09 08:19 <rafa> only
2010-11-09 08:19 <wpwrak> aah, i see
2010-11-09 08:22 <rafa> wpwrak: I did two lists: one list to remove the mpeg* technologies. And another to find forbidden items in Fedora.
2010-11-09 09:36 <wolfspraul> drizzt: are you there?
2010-11-09 09:36 <wolfspraul> you said you have a meeting today, but I would like to postpone my answer until tomorrow, if possible
2010-11-09 09:37 <wolfspraul> also I have a question for you: what kind of products did you outsource/build in this style before? starting with a reference design, and then doing everything else your own/based on your directives?
2010-11-09 09:37 <wolfspraul> were your partners based in France or other countries?
2010-11-09 09:45 <kyak> xiangfu_: are you there?
2010-11-09 09:45 <xiangfu_> kyak: yes
2010-11-09 09:46 <kyak> xiangfu_: abook in openwrt-packages is marked as broken because it needs at least 70x20 terminal.. What do you think if i set it dependent on setfont2 and start abook via wrapper that would first set the 4x6 terminal font which provides even more than 70x20?
2010-11-09 09:50 <xiangfu_> kyak: hmm... how about when abook exit. can it set the font back?
2010-11-09 09:51 <kyak> hm i think i can do it
2010-11-09 09:52 <kyak> setfont .. && abook && setfont ..
2010-11-09 09:53 <kyak> the last setfont won't start until abook exists
2010-11-09 09:53 <kyak> *exits
2010-11-09 09:56 <kyak> (in fact, we can even patch the abook to setfont on start and unset it on exit :)
2010-11-09 09:56 <kyak> got to go now
2010-11-09 11:05 <rafa> wpwrak: fffff.. a package which the source is from maemo has a mp3 inside.. pff
2010-11-09 11:22 <wpwrak> rafa: oh, lovely ;-)
2010-11-09 11:40 <wpwrak> rafa: what is it that package called ?
2010-11-09 11:50 <qi-bot> [commit] Xiangfu Liu: [linux] support increase/decrease in screen brightness http://qi-hw.com/p/openwrt-xburst/edfd9f4
2010-11-09 12:07 <kyak> xiangfu_: awesome, how one can control brightness?
2010-11-09 12:08 <xiangfu_> kyak: /sys/devices/platform/spi_gpio.1/spi1.0/backlight/gpm940b0-bl/brightness ,  0 ~ 255
2010-11-09 12:08 <kyak> great
2010-11-09 12:12 <xiangfu_> kyak: about abook, I will try abook first. then let you know what i am thinking :)
2010-11-09 12:12 <xiangfu_> compiling ...
2010-11-09 12:13 <kyak> xiangfu_: sure.. i noticed that it uses "q" letter instead of frame borders (-). We lack some glyphs in setfont2 fonts
2010-11-09 12:14 <kyak> meanwhile, i'll try this brightness thing :)
2010-11-09 12:24 <rafa> wpwrak:  Package: osso-sounds
2010-11-09 12:25 <rafa> wpwrak:  Source: http://repository.maemo.org/pool/maemo/ossw/source/o/osso-sounds/osso-sounds_0.3-1.tar.gz
2010-11-09 12:26 <wpwrak> hmm, egrep sound|audio ? :-(
2010-11-09 12:27 <kyak> xiangfu_: does work! great job!
2010-11-09 12:28 <rafa> wpwrak: you mean to look for that into every package?
2010-11-09 12:29 <xiangfu_> kyak: the abook compile fine and it can start without change font to 4x6 right? (only cann't edit)
2010-11-09 12:29 <wpwrak> rafa: well, if they're that good at hiding the thing :) but it's probably enough if you scan the files names for MP3 or mp3.
2010-11-09 12:30 <wpwrak> rafa: getting rid of this junk really is harder than it seems :-(
2010-11-09 12:30 <rafa> wpwrak: I did :) I have a text file with the list of files of every package on the repo.. so I can look for file names ;)
2010-11-09 12:30 <wpwrak> ah, cool :)
2010-11-09 12:31 <rafa> wpwrak: I did egrep -i "..mp3$|avi$.. etc.." just that package looks no nice
2010-11-09 12:32 <rafa> wpwrak: but well, there could be some hidden stuff which is not easy to find as you said :(
2010-11-09 12:33 <kyak> xiangfu_: yeah, it doesn't seem to give any warning messages.. but it also doesn't fit to the screen (compare with what you see via ssh or at your PC)
2010-11-09 12:34 <rafa> wpwrak: I tested the www-data user under /srv/www/downloads.qi-hardware.com/ as wolfgang suggested and all is okey. So we have all we need to upload stuff ;)
2010-11-09 12:44 <xiangfu_> kyak: I found if we use "setfont2 ...4x6" in ssh terminal. the nanonote's console will changed.
2010-11-09 12:45 <xiangfu_> kyak: I am testing this for if someone run the "setfont .. && abook && setfont .." in ssh
2010-11-09 12:46 <xiangfu_> kyak: so I think let's just wrap the abook. and add it to config.full_system :)
2010-11-09 12:46 <kyak> xiangfu_: good. let's do it :) give me some time
2010-11-09 12:47 <xiangfu_> kyak: sure
2010-11-09 12:53 <qi-bot> [commit] kyak: abook: wrapper to change font size prior to start http://qi-hw.com/p/openwrt-packages/6a969be
2010-11-09 12:53 <wpwrak> rafa: (www-data) great ! some day, wolfgang will have to set up real user accounts there. it's a bit messy if everyone shares the same account ...
2010-11-09 12:55 <qi-bot> [commit] kyak: forgot the wrapper file for abook... http://qi-hw.com/p/openwrt-packages/8e47e36
2010-11-09 13:07 <xiangfu_> kyak: work pretty good. thanks.
2010-11-09 13:07 <xiangfu_> time for sleep. see you.
2010-11-09 13:08 <kyak> bb
2010-11-09 14:30 <qi-bot> [commit] kyak: abook: use ASCII for drawing boxes http://qi-hw.com/p/openwrt-packages/41b5356
2010-11-09 15:33 <drizzt> back
2010-11-09 15:35 <drizzt> hum .. got to put my son back to bed, I'll be back in a minute
2010-11-09 15:40 <drizzt> back
2010-11-09 15:40 <wpwrak> how did the meeting go ?
2010-11-09 15:41 <drizzt> wpwrak: sorry for leaving, I had to take care of my little girl. That's the price for working at home :)
2010-11-09 15:42 <drizzt> wpwrak: quite well
2010-11-09 15:42 <wpwrak> home offices are indeed more efficient without too many disturbances around :)
2010-11-09 15:42 <wpwrak> kewl, congrats !
2010-11-09 15:43 <drizzt> even better than I could have thought I learnt about this : http://pandaboard.org/content/resources/references
2010-11-09 15:43 <drizzt> hum ... learnt may not be the right word
2010-11-09 15:45 <wpwrak> doesn't seem to have PCIe, though
2010-11-09 15:45 <drizzt> we will have a partnership with my university (CPE-Lyon), and one of the professors pointed me this
2010-11-09 15:46 <drizzt> I haven't looked at it yet
2010-11-09 15:46 <drizzt> just at this page
2010-11-09 15:46 <drizzt> but :
2010-11-09 15:47 <drizzt> Board Revisions & Documentation ... Gerber File ... Schematics ...  Bill of Materials (BOM) ... Allegro Design File ...
2010-11-09 15:47 <drizzt> sounds quite good
2010-11-09 15:49 <wpwrak> i see that you're aligning your requirements with reality. that's good :-)
2010-11-09 15:54 <wpwrak> allegro isn't so nice, though. a proprietary tool.
2010-11-09 15:54 <drizzt> yep
2010-11-09 15:55 <drizzt> I'd rather have kicad
2010-11-09 15:56 <drizzt> do you know if there's a tool to convert between any of the existing CAD formats ?
2010-11-09 15:57 <drizzt> or if some of the tools can save files in a usable format
2010-11-09 15:58 <wpwrak> pheeew ... there are some tools to convert some things. but i'm not sure how usable they are. i've seen a lot of footprint conversions. but then, if you convert from a proprietary system, there's a good change that these libraries will be non-free too.
2010-11-09 15:58 <wpwrak> so it may just be more efficient to redo everything manually and make sure you have a good review process.
2010-11-09 15:59 <wpwrak> drawing schematics symbols and footprints isn't too hard for kicad (if you use fped for the footprints. the footprint editor kicad comes with isn't really usable)
2010-11-09 16:00 <wpwrak> for the layout, you could actually reverse the gerbers. but i'm not sure if this catches all the details. probably not.
2010-11-09 16:00 <wpwrak> (reverse the gerbers) kicad can load a gerber file and convert it into a kicad board file
2010-11-09 16:05 <drizzt> ok
2010-11-09 16:11 <drizzt> so
2010-11-09 16:12 <drizzt> PCI-Express and Sata were kind of "why not, use them if they are here"
2010-11-09 16:13 <drizzt> so this design is rather nice as a starting point
2010-11-09 16:14 <wpwrak> yeah, looks nice. if you can make your device just use the existing board, that would be even easier. that would remove a LOT of work.
2010-11-09 16:14 <drizzt> ethernet over USB is not the best, but the goal is not to build a high bandwidth web server :)
2010-11-09 16:14 <drizzt> yes
2010-11-09 16:17 <drizzt> the Ethernet + 2 USB connector is a bit too big
2010-11-09 16:17 <drizzt> but maybe we can cope with it
2010-11-09 16:17 <drizzt> I'll have to check
2010-11-09 16:19 <wpwrak> wow, the connector is huge indeed
2010-11-09 17:34 <wpwrak> step 1: https://cgran.org/wiki/gr-air-modes    step 2: write the corresponding sender routines ;-)
2010-11-09 18:37 <qbject> wpwrak: are you close to BA?
2010-11-09 18:37 <qbject> and hello. :)
2010-11-09 18:37 <wpwrak> qbject: more or less in the geographic middle of it :)
2010-11-09 18:37 <qbject> Ahh.
2010-11-09 18:37 <qbject> That's cool.
2010-11-09 18:37 <qbject> Just asking because I sometimes fantasize about emigrating to Montevideo.
2010-11-09 18:38 <wpwrak> oh, why montevideo ? kinda boring place
2010-11-09 18:38 <wpwrak> well, better government, i think. not that their argentine counterparts would make that bit particularly difficult :)
2010-11-09 18:38 <drizzt> wpwrak: Buenos Aires ?
2010-11-09 18:38 <qbject> I like meat and freedom. It sounds cheap, compared to places in the US. And I don't need fun, just a lathe, milling machine, and net connection.
2010-11-09 18:39 <wpwrak> drizzt: yup
2010-11-09 18:40 <wpwrak> qbject: yup, argentina is cheap. uruguay probably too. you can get mills and such here too. although imported stuff tends to be more expensive than in the us. about 150-200% of what you'd pay there. for consumer electronics, often even more.
2010-11-09 18:41 <drizzt> ouch
2010-11-09 18:41 <qbject> wpwrak: fair enough. Ideally I'd acquire the equipment here then ship it down. Not sure how tricky the port authorities are to deal with. Then I could BUILD consumer electronics.
2010-11-09 18:42 <drizzt> wpwrak: why are you living there ? any particular reason ?
2010-11-09 18:42 <wpwrak> shipping stuff when you're moving might work. otherwise, it gets very tricky.
2010-11-09 18:43 <drizzt> (maybe I already asked some times ago on gta02-core)
2010-11-09 18:44 <qbject> wpwrak: that's probably how I'd work it. Get a container, move it all in one go.
2010-11-09 18:45 <wpwrak> drizzt: because i like it here :) when i finished my phd, i considered the choices: europe - been there all my life, can go back anytime i want, not much of a challenge. switzerland - been there all my life, getting boring. us - been there for conferences and such, didn't find it too attractive. south america - been there for some conferences and vacations. like it :)
2010-11-09 18:46 <drizzt> ok, by personnal choice then :)
2010-11-09 18:47 <wpwrak> drizzt: yup. for kernel hacking, internet and a pc is all you really need :) i got into playing with hardware later
2010-11-09 18:48 <drizzt> a PC, but with two screens :)
2010-11-09 18:48 <drizzt> which you can have anywhere :)
2010-11-09 18:49 <drizzt> and playing with hardware should be no harder there :)
2010-11-09 18:50 <drizzt> is it you who found the SMT line in a university for gta02-core ?
2010-11-09 18:50 <drizzt> wpwrak: another question, completly independent from all others
2010-11-09 18:50 <wpwrak> drizzt: (pc) three screens, actually :) it's a bit of a challenge to get this to work ...
2010-11-09 18:51 <drizzt> what's your experience in kernel hacking ?
2010-11-09 18:51 <wpwrak> drizzt: (university) that was jon "maddog" hall who "found" the smt line
2010-11-09 18:52 <drizzt> er, not so much of a challenge nowdays, I sometimes have up to five, depending on the place on my desk and what I have at hand (from mimo740 to 24" screens)
2010-11-09 18:53 <drizzt> using synergy makes it easier
2010-11-09 18:53 <wpwrak> drizzt: of the stuff that's in general use today: msdos-fs, initrd, linux-atm, diffserv, some other pieces here and there. did some projects in networking, file system, and of course embedded (linux on the psion s5, later openmoko)
2010-11-09 18:54 <drizzt> I often use my laptop as a third screen
2010-11-09 18:54 <drizzt> KO,
2010-11-09 18:54 <drizzt> OK
2010-11-09 18:54 <drizzt> would you perform code reviews ? (paid, but I'll need a bill)
2010-11-09 18:55 <drizzt> I'm also doing kernel hacking, and I'm writting my first driver "from scratch", so an external look would be nice
2010-11-09 18:56 <wpwrak> (reviews) in what area of the kernel ?
2010-11-09 18:56 <wpwrak> ah, first driver. always fun :)
2010-11-09 18:57 <drizzt> I already asked Greg KH, but his current position prevents him from doing it
2010-11-09 18:57 <drizzt> I already did modifications for specific things, but never designed from scratch
2010-11-09 18:58 <wpwrak> another frequent reviewer is christoph hellwig
2010-11-09 18:58 <wpwrak> what sort of driver ?
2010-11-09 18:58 <drizzt> thats a driver handling communication with a 8051 microcontroller over serial
2010-11-09 18:58 <wpwrak> UART ? or some other kind of serial ?
2010-11-09 18:59 <drizzt> most of it should have gone in userspace, but a few requirements and the fun of it made me do it inside of the kernel
2010-11-09 18:59 <drizzt> pure UART
2010-11-09 19:00 <wpwrak> uart is one of the suckier interfaces ...
2010-11-09 19:00 <wpwrak> (user space) indeed, the art is avoid putting stuff into the kernel ;-)
2010-11-09 19:02 <drizzt> yes
2010-11-09 19:03 <drizzt> but I need to handle an interrupt, and reply in less than 50 ms when this interrupt fires
2010-11-09 19:03 <wpwrak> interrupt coming over some separate line ?
2010-11-09 19:03 <wpwrak> 50 ms seems more than generous enough for user space.
2010-11-09 19:04 <drizzt> but this simple part would have been possible standalone, with some protection, but I must not send the reply in the middle of a message, and not even send it if there's a message being sent
2010-11-09 19:05 <drizzt> yep, quite generous with no system load, but the system will handle video, and the processor is not that good
2010-11-09 19:05 <wpwrak> and who sends the messages ? do of course have all sorts of locks in user space as well ...
2010-11-09 19:05 <wpwrak> (no system load) that's what real-time priorities are for ;-)
2010-11-09 19:06 <drizzt> interrupt over a separate line, yes (gpio)
2010-11-09 19:06 <drizzt> yes, there's a lot of ways to do it in userspace, but as I said, it was for the fun of doing it
2010-11-09 19:07 <drizzt> yep for priorities
2010-11-09 19:07 <drizzt> using it on another project
2010-11-09 19:07 <wpwrak> here's an example for priorities: http://svn.openmoko.org/developers/werner/neodog/neodog.c
2010-11-09 19:07 <wpwrak> ah, okay
2010-11-09 19:08 <wpwrak> interrupts in user space are a problem, though. i wonder if there's still the little political problem that prevents us from having a general mechanism for them.
2010-11-09 19:09 <drizzt> got a state machine in high priority, and a Qt interface in low prio
2010-11-09 19:10 <wpwrak> alright
2010-11-09 19:10 <drizzt> and for the interrupt in userspace, I solved it on a VME board by providing a mechanism for userspace programms to register a signal that the kernel triggers when the interrupt fires
2010-11-09 19:11 <wpwrak> yup. but that's not something that's in mainline, is it ?
2010-11-09 19:11 <drizzt> with some interresting stuff depending on the signal (if I remember, RT signals can stack, thus simulating multiple interrputs)
2010-11-09 19:12 <wpwrak> the political problem being that this would make it possible for a large class of closed-source drivers to be written for user space
2010-11-09 19:12 <drizzt> no, it was a demo VME driver
2010-11-09 19:13 <drizzt> when I was employee, and not as much attached to free software as I am now
2010-11-09 19:14 <drizzt> I was following the guidlines of my employer
2010-11-09 19:14 <wpwrak> hehe :)
2010-11-09 19:15 <wpwrak> yeah, that happens. i also spent some time at ibm :)
2010-11-09 19:15 <drizzt> (one of the reasons that made me resign, and become my own boss :)
2010-11-09 19:15 <wpwrak> yup, freedom is good to have
2010-11-09 19:15 <drizzt> so, can I forward you the email for the review ?
2010-11-09 19:18 <wpwrak> i can have at least a quick look ...
2010-11-09 19:18 <drizzt> ok, I forwarded the original mail
2010-11-09 19:25 <wpwrak> better to avoid lines > 80 characters
2010-11-09 19:26 <wpwrak> see also linux-*/Documentation/CodingStyle, chapter 2, 2nd paragraph :)
2010-11-09 19:26 <drizzt> yes, I know, but my screen are much wider than they are high
2010-11-09 19:28 <wpwrak> the terminals of the readers of your code may not be, though
2010-11-09 19:29 <drizzt> do not take care about anything marked /* debug */
2010-11-09 19:29 <drizzt> or lines starting with "/* */"
2010-11-09 19:29 <wpwrak> line 1805 s/if(/if (/
2010-11-09 19:30 <drizzt> those have been added afterwards to allow the author of the 8051 firmware to debug his code
2010-11-09 19:32 <drizzt> yep, thanks
2010-11-09 19:34 <wpwrak> hmm, is the CRC different from the one in lib/crc-ccitt.c ?
2010-11-09 19:34 <drizzt> mind that the conditions in the mail still apply
2010-11-09 19:35 <drizzt> from my tests yes
2010-11-09 19:35 <wpwrak> ah, conditions ... you mail is kinda hard to read too, with all the oversized lines ...
2010-11-09 19:36 <drizzt> maybe just a question of initial value, but I tried a lot of tools on the net before getting one wich gave me the same CRC as the 8051
2010-11-09 19:36 <wpwrak> crcs can be incredibly tricky, yes
2010-11-09 19:36 <drizzt> and I'm not so good with these kind of stuff
2010-11-09 19:37 <drizzt> so when I found one which matched, and which gave C code for the implementation ...
2010-11-09 19:37 <drizzt> I can pay for two hours for you and two hours for another kernel developer which would be
2010-11-09 19:37 <drizzt> interrested, at a rate of 110 euro per hour (+ taxes) (total of 440 euros without taxes).
2010-11-09 19:38 <drizzt> so two hours for you :)
2010-11-09 19:39 <xiangfu> wpwrak: Hi I got one email "fped_0.0+r5986-1_amd64.changes ACCEPTED into unstable"  :)
2010-11-09 19:40 <xiangfu> wpwrak: forwarding to list
2010-11-09 19:40 <wpwrak> xiangfu: congratulations ! now wolfgang owes you a crate of champagne  ;-)
2010-11-09 19:40 <wpwrak> drizzt: kewl. the EI_KEY_... stuff wants to be an enum
2010-11-09 19:41 <wpwrak> linux/embedded_interface.h is missing
2010-11-09 19:41 <drizzt> yes, it is in the userspace code, and here it will be removed
2010-11-09 19:42 <drizzt> the driver does not care about what the key means
2010-11-09 19:42 <drizzt> (they are all unused)
2010-11-09 19:42 <wpwrak> i see
2010-11-09 19:43 <drizzt> same for EI_LED_*
2010-11-09 19:43 <wpwrak> may be better if you do the clean up you've already planned first ? not much use to review stuff that'll go away anyway. that is, unless you want to compare coverage ;-)
2010-11-09 19:44 <drizzt> I had not much time to do so when I sent the first request
2010-11-09 19:45 <wpwrak> you have a few indentations made up of spaces. if using vi, you can find them with /^__ (where _ would be a space)
2010-11-09 19:46 <drizzt> the author of the 8051 firmware wanted to review my code because he said that my handling of the protocol was wrong and generated the problems I reported, such as 8051 resets, messages getting lost, crc errors, ...
2010-11-09 19:46 <wpwrak> heh :)
2010-11-09 19:46 <drizzt> so I also asked for a review from someone used to kernel drivers
2010-11-09 19:47 <drizzt> but during the meeting with the custommer he finaly left behind the idea of reviewing my code
2010-11-09 19:47 <wpwrak> first pass is always use of whitespace :)
2010-11-09 19:48 <drizzt> whatever mistake I could have made, the 8051 should not reset itself ...
2010-11-09 19:48 <drizzt> so he decided to review his code first
2010-11-09 19:48 <wpwrak> unless it's spec'ed to reset when confused
2010-11-09 19:49 <drizzt> leading spaces corrected (i love vi :)
2010-11-09 19:50 <drizzt> not at all, rather the contrary
2010-11-09 19:50 <wpwrak> more whitespace, e.g., line 425: it should be  struct message *free  not  struct message* free  (CS 3.2, 4)
2010-11-09 19:50 <wpwrak> you also occasionally don't put a blank line between block-local declarations and statements, e.g., in emb_intf_put_free_message
2010-11-09 19:51 <drizzt> the 8051 should be the "security" part, cutting everything off in case of problem
2010-11-09 19:51 <wpwrak> global declarations between functions aren't so nice either (partial)
2010-11-09 19:51 <drizzt> it's a medical device (not a critical one, you can keep going to the hospital)
2010-11-09 19:52 <wpwrak> (safety-critical) ah yes, then a reset every now and then isn't so good :)
2010-11-09 19:53 <drizzt> (message *free) : this is a "bad habbit" of mine
2010-11-09 19:53 <drizzt> in fact, moving the '*' from "message *free" to "message* free" made me understand pointers
2010-11-09 19:54 <wpwrak> (bad habit) yup. i see it at a few places :)
2010-11-09 19:54 <drizzt> I would say everywhere
2010-11-09 19:54 <wpwrak> btw, you can save space by not indenting the "case" in a switch, see CS 3, par 2
2010-11-09 19:56 <drizzt> what's strange is that every time someone has difficulties with pointers, explaining with the '*' next to the type and not the name makes them understand (along with a short explanation)
2010-11-09 19:57 <wpwrak> hehe, that makes sense
2010-11-09 19:57 <wpwrak> for commenting struct members, it improves readability dramatically if you align the comments
2010-11-09 19:57 <drizzt> (struct message*) free   <-- free is a (struct message*)  <-- free is a pointer to something of the type (struct message)
2010-11-09 19:58 <drizzt> and then (*free) becomes obviously ("the something of the type (struct message)
2010-11-09 19:59 <drizzt> this is what had me understand pointers, and allowed me to explain to many other students
2010-11-09 20:00 <drizzt> I sometimes wonder if the professor was that good though ...
2010-11-09 20:00 <wpwrak> regarding the CRC, did you check if the one in lib/crc-ccitt.c is really different ? i see that you have a funny initial value.
2010-11-09 20:01 <drizzt> (crc) yes, I know it may be only a matter of initial value
2010-11-09 20:02 <drizzt> I did not chek inside of kernel, but I put the kernel version in a userspace test programm, and got different values
2010-11-09 20:02 <drizzt> but at that time I did not try to change the initial value
2010-11-09 20:03 <drizzt> I had no knowledges about CRC (and I still have very few)
2010-11-09 20:03 <wpwrak> okay, so you looked at that one. good. i wonder where the initial value comes from. also, it's a pity the polynom isn't specified.
2010-11-09 20:04 <wpwrak> whenever i've figured out crcs enough for them to make sense, i have to drink a lot afterwards, to forget all this again as quickly as possible ;-)
2010-11-09 20:05 <drizzt> I finally found this :
2010-11-09 20:05 <drizzt> http://www.lammertbies.nl/comm/info/crc-calculation.html
2010-11-09 20:05 <drizzt> with the crc called "CRC-CCITT (0x1D0F)"
2010-11-09 20:06 <drizzt> and as 1D0F was mentionned in the documentation of the 8051 programm, i gave it a try
2010-11-09 20:06 <wpwrak> aah ! well, your algorithm swaps the bytes. so it may be 0x0f1d.
2010-11-09 20:08 <drizzt> maybe that's why I never managed to used those which proposed to set the initial value, as I should have tried 0x0f1d and not 0x1d0f
2010-11-09 20:10 <wpwrak> the table looks different too, though. not sure what to make of this.
2010-11-09 20:10 <drizzt> the table is generated in the example found on the website
2010-11-09 20:11 <drizzt> I printed it to prevent calculation upon startup
2010-11-09 20:11 <drizzt> (printed and put it in my code)
2010-11-09 20:12 <wpwrak> yup, that's common practice. nothing wrong with that.
2010-11-09 20:13 <wpwrak> just having your own private implementation of an apparently "standard" CRC in a driver is something people will complain about when you submit this for mainline inclusion
2010-11-09 20:14 <drizzt> hum .. I can send this for mainline, but I do not see the point, it's related only to the protocol on a single product ...
2010-11-09 20:14 <wpwrak> you seem to have a number of code patterns in "struct embeded_intf", such as flags_* and key_*, also with very long names. could it be cleaner to introduce a "struct ei_queue" or such for these ?
2010-11-09 20:15 <wpwrak> ah, i see. thought you were interested in getting it into shape for mainline submission
2010-11-09 20:15 <drizzt> it will be in the sources provided with the product (I'll put it on the internal system SD :)
2010-11-09 20:16 <drizzt> I wanted to know if it would be OK for mainline submission
2010-11-09 20:17 <wpwrak> drizzt: you could simplify things by making curr_msg_id an uint8_t
2010-11-09 20:17 <drizzt> I can send it, as an exemple, but then it may be much more usefull on the web, outside the kernel, with the protocol and some explanations
2010-11-09 20:18 <drizzt> though I think the protocol is under NDA .... :(
2010-11-09 20:18 <drizzt> but it's quite easy to find from the sources :)
2010-11-09 20:19 <drizzt> and it's such a bad thing that it's better not to make it public
2010-11-09 20:19 <wpwrak> yeah, sources tend to give such things away :)
2010-11-09 20:20 <wpwrak> the messages do look a little strange indeed
2010-11-09 20:20 <drizzt> (the value 100 is sent as the string "100", not as 0x64)
2010-11-09 20:20 <drizzt> so it's 3 bytes on wire, not one
2010-11-09 20:21 <drizzt> and then, some messages have been split in three, to keep them short
2010-11-09 20:21 <drizzt> they told me it was for "readability"
2010-11-09 20:22 <drizzt> a human can read it, and write it very easily ..
2010-11-09 20:23 <drizzt> but in fact, this is so much wrong .. I have some difficulties with the CRC calculation without a programm ...
2010-11-09 20:24 <drizzt> so all the protocol should be rewritten .. but won't ever.
2010-11-09 20:26 <drizzt> yep for the paterns
2010-11-09 20:26 <drizzt> flags, but also wait queues
2010-11-09 20:27 <drizzt> hum, your version does not have the wait_queues
2010-11-09 20:27 <wpwrak> haven't gotten to the wait queues yet. btw, minor nit: you could strip one layer of parentheses in lines 516 and 525
2010-11-09 20:27 <wolfspraul> wpwrak: fped is in Debian unstable :-)
2010-11-09 20:27 <wolfspraul> so is xburst-tools
2010-11-09 20:28 <drizzt> had to intriduce them to put userspace programm to sleep while waiting for the replys
2010-11-09 20:28 <wpwrak> wolfspraul: world dominaton just got a little closer :-)
2010-11-09 20:28 <wpwrak> drizzt: why, busy-waiting is so much more impressive ;-)
2010-11-09 20:29 <drizzt> lol
2010-11-09 20:29 <wpwrak> drizzt: also, if (...) { single-statement; }  doesn't need the curly braces. again, some space saved :)
2010-11-09 20:29 <drizzt> specially when the doctor is looking at the video
2010-11-09 20:30 <wpwrak> drizzt: the 'b' case in emb_intf_handle_reply could go to a separate function. this also reduces the indentation level
2010-11-09 20:30 <drizzt> hum, i stick to these since i often add debug and forget to add the curly braces, then wonder what's going on ....
2010-11-09 20:31 <drizzt> right for 'b' case :)
2010-11-09 20:34 <wpwrak> 'c' case etc., the memcpys look unwieldy and they probably aren't portable either. how about emb_intf.voltages.val_5v0 = read_param(reply, 0);  with a suitable read_param function ?
2010-11-09 20:34 <drizzt> and the switch becomes readable :)
2010-11-09 20:34 <wpwrak> 'f' and 'g' also look as if they could be simplified
2010-11-09 20:35 <drizzt> yes
2010-11-09 20:35 <drizzt> h too (same simplifacation in fact)
2010-11-09 20:39 <wpwrak> drizzt: emb_intf_handle_received_message: if (!(msg->type & 0xf000)) { .... and then if (!(msg->type & 0xf000)) { again ?
2010-11-09 20:39 <wpwrak> and again, this HUGE if should be a separate function
2010-11-09 20:41 <wpwrak> and you could make emb_intf_handle_received_message a wrapper. spin_lock_irqsave(); if () __emb_intf_handle_received_message(); spin_unlock_irqsave();
2010-11-09 20:41 <wpwrak> then you don't need to worry abou the lock inside __emb_intf_handle_received_message() and the code gets a lot easier to review
2010-11-09 20:42 <wpwrak> ah wait .. you unlock it again inside. sigh.
2010-11-09 20:43 <drizzt> emb_intf_send_message(request); <--- .. yep
2010-11-09 20:43 <drizzt> that's it
2010-11-09 20:44 <drizzt> and there's other place where I need such things because of code that may sleep
2010-11-09 20:45 <drizzt> emb_intf_put_free_message
2010-11-09 20:46 <drizzt> (not sleep here, but lock too)
2010-11-09 20:46 <wpwrak> i see the lock-list_empty-del-unlock idiom quite a number of times. may be worth putting this into some helper function
2010-11-09 20:48 <wpwrak> see also CS 6: "Functions should be short and sweet, and do just one thing.  They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well."
2010-11-09 20:48 <wpwrak> perhaps the single most important rule ;-)
2010-11-09 20:49 <drizzt> yes, I should cut in many more functions
2010-11-09 20:49 <wpwrak> this often also helps to spot a pattern that leads for further simplificaiton
2010-11-09 20:50 <drizzt> they tend to grow and I do not split them enought
2010-11-09 20:50 <wpwrak> it's like peeling an onion. with each layer of complexity you remove, the layer below becomes more visible
2010-11-09 20:53 <wpwrak> eek. emb_intf_handle_cmd_set: case doesn't need curly braces
2010-11-09 20:54 <wpwrak> the mask in ((val >> 16) & 0xffff is redundant if val is an uint32_t
2010-11-09 20:55 <wpwrak> drizzt: i also see that your faith in operator precedence is weakening in this function. there's a lot of parentheses you don't need
2010-11-09 20:56 <wpwrak> a lot of the message generation looks like stuff that could live in user space ?
2010-11-09 20:57 <drizzt> yes
2010-11-09 20:57 <drizzt> (the whole driver should)
2010-11-09 20:58 <drizzt> but this way the user space does not care about the protocol
2010-11-09 20:59 <drizzt> else there would be parts in the kernel and parts in the user-space
2010-11-09 21:00 <drizzt> and it's an "arrangment" with the person who does the user-space tool
2010-11-09 21:00 <drizzt> so he just have to use a few ioctl
2010-11-09 21:01 <drizzt> he wanted to kill the man who wrote the protocol when he read it
2010-11-09 21:01 <wpwrak> hmm. i wonder if the whole locking logic is really right. e.g., emb_intf_data_process -> emb_intf_handle_received_message -> emb_intf_handle_reply can sleep. and so can emb_intf_handle_cmd_get. yet you're using a spinlick for key_lock
2010-11-09 21:01 <wpwrak> spinlOck
2010-11-09 21:02 <wpwrak> or wait .. not sure about it being able to sleep ... lemme check ..
2010-11-09 21:03 <wpwrak> yes, it can. there's a "down" there :)
2010-11-09 21:03 <drizzt> key_lock ?
2010-11-09 21:04 <wpwrak> emb_intf.key_lock
2010-11-09 21:05 <drizzt> yep, but there's no function call between the lock and unlock
2010-11-09 21:06 <wpwrak> what i mean is that both are in a context where the can sleep. so why a spinlock ?
2010-11-09 21:07 <drizzt> only used in two places, with only tests and affectations between
2010-11-09 21:07 <drizzt> ha
2010-11-09 21:08 <drizzt> we can sleep outside the lock
2010-11-09 21:08 <drizzt> but not while holding the lock
2010-11-09 21:08 <wpwrak> sure, but since you can sleep, you may as well use a mutex to protect the data, no ?
2010-11-09 21:08 <drizzt> yes
2010-11-09 21:09 <drizzt> i already moved from spin_lock_irqsave to spin_lock
2010-11-09 21:10 <wpwrak> you have very complex locking in that driver. almost half of the code is some spin_lock/spin_unlock. this seems unusually hard.
2010-11-09 21:10 <drizzt> maybe I' mistaken, but they are as good as mutexes if the code inside does not sleep
2010-11-09 21:11 <wpwrak> well, you could aim for a lower density of locking operations
2010-11-09 21:12 <drizzt> most of the locking is around the list handling
2010-11-09 21:13 <wpwrak> yes. couldn't a single mutex handle this as well ? i.e., do you really need this sort of granularity
2010-11-09 21:13 <wpwrak> ?
2010-11-09 21:13 <drizzt> and i tried a version with less locking, but got problems with the lists (oops on "poison" elements)
2010-11-09 21:14 <drizzt> and for the granularity, yes, the buffer for receiving data is very small, if i stay locked too long i loose data
2010-11-09 21:14 <drizzt> but a version with mutex may solve both problems
2010-11-09 21:15 <drizzt> you're right
2010-11-09 21:16 <drizzt> at least some lists do not need irqsave locking
2010-11-09 21:16 <wpwrak> the only obviously tricky bit seems to be davinci_gpio7_interrupt
2010-11-09 21:17 <drizzt> and I finally removed the list from the interrupt, replacing it by a flag
2010-11-09 21:17 <drizzt> yep
2010-11-09 21:17 <drizzt> I had list handling in there at the beginning
2010-11-09 21:17 <wpwrak> yup, you already decoupled this
2010-11-09 21:17 <drizzt> but no more
2010-11-09 21:17 <wpwrak> (had list handling there) hence the large number of spinlocks :)
2010-11-09 21:17 <drizzt> then the mutex should be better
2010-11-09 21:18 <drizzt> yep
2010-11-09 21:18 <drizzt> had to be irqsafe whenever handling lists
2010-11-09 21:18 <wpwrak> i'm not enirely sure about emb_intf_tty_receive_buf ... lemme see if i can find something
2010-11-09 21:18 <drizzt> no more now
2010-11-09 21:19 <drizzt> this one i must leave as is
2010-11-09 21:19 <drizzt> it's a tty lock
2010-11-09 21:20 <drizzt> at least it's what's done in tty drivers in the kernel (this parts has it's roots there)
2010-11-09 21:20 <wpwrak> okay, and it's decoupled, too. good.
2010-11-09 21:22 <wpwrak> now, if we could get rid of these global variables, it would be perfect
2010-11-09 21:26 <drizzt> these ?
2010-11-09 21:26 <drizzt> emb_intf ?
2010-11-09 21:26 <wpwrak> i'm not entirely sure, but my guess would be that you could put a pointer to emb_intf into driver_data
2010-11-09 21:27 <drizzt> there's only one, and it lives accross all the driver life
2010-11-09 21:27 <wpwrak> emb_intf, partial, i think there's more. you hid them well :)
2010-11-09 21:27 <drizzt> hum, yes
2010-11-09 21:27 <wpwrak> how about having multiple instances of the driver ? :)
2010-11-09 21:27 <drizzt> no
2010-11-09 21:27 <drizzt> only one instance of the tty line !
2010-11-09 21:28 <drizzt> that's a hard limit
2010-11-09 21:28 <wpwrak> it's still nice to make the code "proper"
2010-11-09 21:28 <drizzt> you've got one point :)
2010-11-09 21:28 <drizzt> there's also "sending"
2010-11-09 21:29 <wpwrak> particularly when submitting into mainline, there's always the risk of someone copying the example without being aware of the limitation
2010-11-09 21:30 <drizzt> ei_trace and ei_dbg, but these are for the "debug" version, and will go away with the debug code when the 8051 firmware is OK
2010-11-09 21:31 <wpwrak> yeah, i didn't look at the dbg things, like you said
2010-11-09 21:31 <drizzt> nice :)
2010-11-09 21:31 <wpwrak> embeded_intf_remove can lose one level of indentation as well. handle the if first and return immediately. voila :)
2010-11-09 21:32 <drizzt> ho, yes :(
2010-11-09 21:35 <drizzt> though when development will be over this won't be a module anymore
2010-11-09 21:35 <wpwrak> why not ?
2010-11-09 21:35 <drizzt> it's easier for development :)
2010-11-09 21:36 <drizzt> because it must be here before the system finds it's init and rootfs
2010-11-09 21:36 <drizzt> the 8051 is sending his first interrupts long before this, and with ne answer it goes into error
2010-11-09 21:37 <wpwrak> oh, i see. a case for initramfs ?
2010-11-09 21:38 <drizzt> we cope with this for the development, but the medical persons won't like the error led and bip to turn on at every startup
2010-11-09 21:39 <drizzt> no real incidence here (initramfs)
2010-11-09 21:39 <drizzt> the system boots on SD, and the module could be loader immediatly
2010-11-09 21:40 <drizzt> loaded
2010-11-09 21:40 <wpwrak> they're used to these devices that go BEEEEEEEP all the time :)
2010-11-09 21:40 <drizzt> but this is still too long, unless I manage to shorten the boot time
2010-11-09 21:40 <wpwrak> seems a little odd to have such a tight timeout
2010-11-09 21:41 <wpwrak> i mean, what good is the driver if the application isn't ready ?
2010-11-09 21:41 <drizzt>  three seconds
2010-11-09 21:41 <drizzt> just to reply to the "heartbeat"
2010-11-09 21:41 <wpwrak> seems that the application should initiate the communication. the 8051 could time out a good while later.
2010-11-09 21:42 <drizzt> (it's one of the purposes of the interrupt)
2010-11-09 21:42 <wpwrak> well, have a longer timeout before the first heartbeat
2010-11-09 21:42 <drizzt> this is one of my requests to the 8051 firmware developper
2010-11-09 21:42 <wpwrak> ah, one more ting: the params .. they're binary in the data that gets sent around, right ?
2010-11-09 21:43 <drizzt> in the protocol ?
2010-11-09 21:43 <drizzt> between 8051 and kernel ?
2010-11-09 21:43 <wpwrak> yes
2010-11-09 21:44 <drizzt> they are ascci representations of the values
2010-11-09 21:44 <drizzt> to send 100, you must "write" the string "100"
2010-11-09 21:44 <drizzt> not 0x64
2010-11-09 21:45 <drizzt> hence the sprintf and scanf
2010-11-09 21:45 <wpwrak> oh, and fixed-format. not 100 but 0100,... ?
2010-11-09 21:45 <drizzt> yep
2010-11-09 21:46 <drizzt> "<d,01,0100>A01E" for example
2010-11-09 21:46 <drizzt> with even the CRC being sent "A01E" for 0xA01E !
2010-11-09 21:48 <drizzt> and i spent a lot of time before understanding that it's "A01E" and not "a01e"
2010-11-09 21:48 <wpwrak> oh dear. prt[8] ;-))
2010-11-09 21:48 <drizzt> ?
2010-11-09 21:48 <wpwrak> i mean ptr
2010-11-09 21:48 <drizzt> prt[8] ?
2010-11-09 21:49 <drizzt> ? ptr = ?
2010-11-09 21:49 <drizzt> lol ?
2010-11-09 21:49 <wpwrak> was this once ptr[4] ? ;-) then, when it crashed, you went to ptr[8] ? :) (in emb_intf_handle_cmd_set)
2010-11-09 21:50 <drizzt> ho, no
2010-11-09 21:50 <drizzt> I begun with 8
2010-11-09 21:50 <drizzt> and left it so
2010-11-09 21:50 <wpwrak> anyway, looks correct. just very odd, the whole thing. now i also understand why you have that memcpy there
2010-11-09 21:53 <wpwrak> i didn't spot anything evil in the rest. i'm a bit rusty on recent kernel interfaces and may have missed some atrocities, so you may want to try someone like christoph or lars for the 2nd run, after the basic cleanup
2010-11-09 21:53 <drizzt> ok
2010-11-09 21:53 <drizzt> I'll check the mutex for the lists
2010-11-09 21:53 <drizzt> but thanks a lot :)
2010-11-09 21:54 <wpwrak> you've logged the conversation ?
2010-11-09 21:54 <drizzt> please, send me a bill, or at least a way to send you the money
2010-11-09 21:54 <drizzt> yes
2010-11-09 21:54 <drizzt> it's all saved :)
2010-11-09 21:55 <drizzt> I'm paid for this job, so you should be for the review :)
2010-11-09 21:55 <wpwrak> (bill) i'll do the "paperwork" tomorrow. need to search for the stuff :)
2010-11-09 21:55 <drizzt> perfect
2010-11-09 21:56 <wpwrak> great. a bit of income is always a good change from the current 100% hobby work ;-)
2010-11-09 21:56 <drizzt> you'll find all information there : http://www.ed3l.fr/index_en.php?page=contacts
2010-11-09 21:57 <wpwrak> excellent, thanks !
2010-11-09 21:58 <drizzt> I may have one more important review to do, for small modifications, bet for mainline submitions in the future
2010-11-09 21:58 <wpwrak> i have an account in switzerland, so i'll deprive you of the opportunity of learning the strange rituals involved in sending money to argentina
2010-11-09 21:58 <wpwrak> review of this driver ? or something else ?
2010-11-09 21:59 <drizzt> it's for patches I made for Alcatel lucent, for usb-serial drivers
2010-11-09 22:00 <drizzt> and modifications to ppp, to reach theorical up and download speed on 3G, HSUPA and HSDPA networks
2010-11-09 22:00 <drizzt> they are under testing in their labs
2010-11-09 22:01 <wpwrak> wow. i can review it for style and general issues. for conflicts with the existing design, you'd have to get feedback directly from the people in charge
2010-11-09 22:01 <drizzt> moved from 25% to near 100% of theorical rates :)
2010-11-09 22:01 <wpwrak> not bad :)
2010-11-09 22:02 <drizzt> better than the other test suites thay had with other systems
2010-11-09 22:02 <drizzt> and in this case, they'll even pay me for the job of submitting to the kernel
2010-11-09 22:03 <wpwrak> that's how it should be
2010-11-09 22:03 <drizzt> :)
2010-11-09 22:03 <drizzt> yes
2010-11-09 22:03 <drizzt> so, I need to get a few hours of sleep (it's 4 am here)
2010-11-09 22:03 <drizzt> got to get up at 8
2010-11-09 22:03 <wpwrak> ah yes. and i should get some dinner. midnight :)
2010-11-09 22:04 <drizzt> so, "see" you tomorow :)
2010-11-09 22:04 <drizzt> ++
2010-11-09 22:04 <wpwrak> sweet dreams ! :)
2010-11-09 22:06 <wpwrak> i hope all the off-topic stuff didn't scare the rest of the audience too much :) since a lot of it was actually general kernel style issues, i think it may have some use here, too
2010-11-09 22:07 <drizzt> hum, yes, we could have done it in private