Back
[01:26:36] <memleak> Nobody can pull of a faux hawk better than I can :P
[01:26:48] <memleak> i think that's actually my github profile picture..
[01:27:04] <memleak> heh, yeah, it is.
[01:37:55] <seb_kuzminsky> http://highlab.com/~seb/simon-mohawk.jpg
[01:40:45] <memleak> haha that's cute!
[03:40:21] <memleak2> KimK: not exactly sure what you're trying to do but you can always run a git diff HEAD (or HEAD~ if it's committed in your local repo) then rebase the code (if needed) against the newer branch.
[03:42:32] <memleak2> its ugly but it's failsafe. Something like this: git add -A && git diff HEAD &> ../my_patch.patch && git reset --hard HEAD && git pull && git checkout origin/<new branch that you want to push against> && patch -p1 < ../my_patch.patch && git push
[03:43:19] <memleak2> my nick is messed up, one moment..
[03:45:34] <memleak> sorry about that..
[03:48:37] <memleak> use HEAD~ if you committed your changes at all, if it's several commits behind than where you currently are, the syntax is either HEAD~~ -> HEAD~~~ or HEAD~1 -> HEAD~2
[03:48:49] <memleak> etc etc
[05:10:14] <memleak> I've been re-writing a lot of 64-bit interrupt code in RTAI, it's difficult though because not even in the Linux kernel does it do all the low-level stuff that the 32-bit kernels have to offer.
[05:12:21] <memleak> Flat memory, direct PCI mapping, basically just a much simpler and lower-level way to do everything the 64-bit kernel does. 64-bit always has these round-about methods, it's driving me crazy.
[05:14:04] <memleak> It'd be a lot easier if 64-bit kernel code was just 32-bit but with 64-bit extensions. But nope, not gunna happen.
[06:17:27] <memleak> In only an hour I made quite of bit of progress. Only some minor APIC justifications left and 64-bit RTAI will run the same the 32-bit side :)
[06:17:44] <memleak> *as the 32-bit side
[06:17:59] <memleak> Good night all! 6am now.
[13:37:37] <mhaberler> jepler: the reason why on master and the ub branch the userside HAL behavior is different is so: in the ub branch, the shared library constructor does a lot of work (determin flavor, find ulapi-<flavor>.so, load that, and initialize) ; there is no such thing on master - it isnt noticed until you actually access HAL
[13:41:04] <jepler> mhaberler: OK, can you look at putting off that work until rtapi_init?
[13:42:33] <mhaberler> need to think about it; note that logging goes through the shm segs rtapi_msgd sets up too, so that is a lot of dependencies being up in the air
[13:43:41] <mhaberler> we did discuss this and I said this was coming, quite a while ago
[15:29:06] <jepler> this new requirement is going to be at best very irritating to meet
[15:29:57] <jepler> for example, stepconf and pncconf won't work anymore, because they 'import hal' and then start and stop hal sessions while running
[15:30:12] <jepler> (stepconf in a way that works and pncconf in a way that has problems at present)
[15:30:47] <jepler> whatever the work is, why not just move it to the top of rtapi_init?
[17:09:56] <mhaberler> jepler: one stopgap measure would be to remove the '#<hal[pin]>' feature in the interpreter (this should be redone queued anyway); this would resolve most issues I think; need to query about usage
[17:13:18] <mhaberler> re delaying to rtapi_init().. that is a chicken-and-egg issue - environment detection needs to ascertain the proper ulap-<flavor>.so is loaded and that contains the rtapi_init() _for the by-then-chosen flavor_
[17:14:29] <mhaberler> the only way I see is to track this in hal_init() and call the constructor from there
[17:26:59] <mhaberler> hm, looks like doing it from hal_init() might work after all; this of course does not apply to halcmd
[17:31:14] <mhaberler> it is a pity that API initalisation is married to component creation
[17:32:09] <mhaberler> it works for rs274 but I need to look at the code to make sure it's serially reusable on failure to attach
[17:45:53] <mhaberler> ok, I will try, but I do not commit to this because this seriously botches assumptions about startup sequencing and error reporting, and I might have to back this out after all - I will not reconsider startup sequencing because of this nit, this was a super hard nut to crack and I'm just not going there for that minor upside
[17:47:42] <jepler> we've identified that your tree will cause regressions in e.g., stepconf and rs274, so that needs to be addressed.
[17:48:23] <mhaberler> 'your tree' being? and what is the relation to what we discussed?
[17:49:34] <jepler> the same thing we've been talking about, where you can't even be linked with liblinuxchcnal.so and start without realtime going
[17:51:00] <mhaberler> let me remind you I stated this very clearly: we need to start realtime before anything, even for what used to be 'sim'; and you considered it an acceptable price
[17:51:28] <jepler> obviously I misunderstood
[17:51:35] <jepler> "anything" I assumed was *calling* an API
[17:53:20] <mhaberler> sorry - I need to take your word for it; too far down the road do discuss misunderstandings. My offer is 'best effort' but not 'must have at all cost'.
[17:54:24] <mhaberler> could you share details about the stepconf and rs274 regressions? first time I hear about it
[17:54:33] <jepler> you have been TELLING ME ABOUT THEM
[17:54:53] <jepler> well I am generalizing from your explanation about rs274 to other programs that link with liblinuxcnchal.so but make no API calls
[17:54:58] <mhaberler> oh I see
[17:55:05] <mhaberler> oh oh oh
[17:55:46] <mhaberler> I thought you were off to a private investigation ;)
[17:58:59] <mhaberler> ok, fair enough. the rough part is making sure rtapi logging functions work regardless; pretty sure they do
[18:00:36] <jepler> idea: if rtapi_print is before rtapi_init, just pass it to vfprintf stderr
[18:01:42] <mhaberler> I think it does, but need to check. I'm off for a few days, so you'll hear after you return (vacation?)
[18:03:17] <mhaberler> yes, reading the code it's ok
[18:04:42] <mhaberler> I did work on the assumption that before anything starts, a separate per-instance shm segment is set up which helps coordinate the instance and also carries the logging ring buffer
[18:05:58] <mhaberler> so the invariant for rtapi+hal are: before anything happens this segment is attached, only then rtapi_data and hal_data plus others come to life
[18:06:59] <jepler> if rs274 (which you've tested and know it doesn't) and stepconf (which I haven't tested but guess will be affected) work then I will feel good
[18:07:06] <jepler> I don't know if I've accurately stated what the invariant needs to be
[18:07:10] <mhaberler> uncoordinated entitites and autodetect are a recipe for going haywire, so that was the solution that took care of it: decide once what the flavor is, and everythin goes from there
[18:08:40] <mhaberler> I would think is - linking liblinuxcnchal will not fail startup if no realtime; it will fail hal_init(), and rtapi_print* must work in some way
[18:09:02] <mhaberler> but the hal_init() failure isnt fatal
[18:11:04] <mhaberler> hm, I have an idea
[18:11:56] <mhaberler> the rtapi functions go through a devsw type struct and the only connection between hal and rtapi is the pointer to this rtapi_sw
[18:12:40] <mhaberler> I could do a dummy rtapi_sw in hal which makes all functions return -ENOSYS or so if not loaded, instead of doing something less than nice
[18:13:35] <mhaberler> so hal_lib() statically inits rtapi_switch to this noop switch which makes sure the rtapi functions dont segfault, the just return an errorcode
[18:14:01] <mhaberler> actually that should have been part of it to start with
[18:15:38] <mhaberler> and successfully loading the proper ulapi.so sets the rtapi_switch to point to the real one
[18:15:40] <mhaberler> done.
[18:16:02] <mhaberler> much nicer scheme and more robust
[18:17:45] <mhaberler> yep, that's it, I think we have a go
[18:18:06] <jepler> whee, I'm glad you were willing to take another look
[18:18:07] <jepler> thank you
[18:19:20] <jepler> bbl
[18:19:22] <mhaberler> that was a 'duh'. but then I cooked up all the basics pretty much in isolation, so that wasnt unlikely to happen
[18:19:24] <mhaberler> anyway, I'm off - cu, and have fun days
[18:19:29] <jepler> thank you
