| 00:03.56 | calculus | xml how? parsing, structure, schemas, xslt, integration with language x |
| 00:04.27 | prpplague | more schemas and structure |
| 00:04.49 | prpplague | i think they are doing some xml based content management |
| 00:06.29 | calculus | sorry, I have mainly done parsing |
| 00:07.01 | calculus | the structure tends to be <tagname attribute="attribute-value">stuff</tagname> |
| 00:07.29 | calculus | and only one root tag per xml file |
| 00:07.51 | calculus | and comments are <!-- comment --> |
| 00:08.09 | prpplague | ahh |
| 00:08.23 | prpplague | calculus: it was a long shot, just wanted to recommend something to a friend |
| 00:43.11 | *** join/#edev djerome (~djerome@ip68-2-20-108.ph.ph.cox.net) |
| 02:39.57 | *** join/#edev JoeLlama (~snork@cpe-75-85-45-219.socal.res.rr.com) |
| 02:39.57 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 03:23.56 | *** join/#edev JoeLlama (~snork@cpe-75-85-45-219.socal.res.rr.com) |
| 03:23.58 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 03:25.08 | *** join/#edev MonMotha (~monmotha@2001:470:c5f2:1:224:7eff:fedc:893e) |
| 03:25.30 | MonMotha | so, thoughts on preferred Linux distro for "I do development but I don't want to mess with things unnecessarily" users? |
| 03:57.38 | calculus | MonMotha: that reminds me, linux tycoon http://lunduke.com/?page_id=2646 |
| 03:58.27 | MonMotha | calculus: hah |
| 04:16.45 | *** join/#edev mbuf (user@nat/redhat/x-dfpppkgedojsufce) |
| 04:41.47 | *** join/#edev risca (~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net) |
| 05:15.45 | *** join/#edev MonMotha (~monmotha@2001:470:c5f2:1:224:7eff:fedc:893e) |
| 05:25.26 | *** join/#edev JoeMoose (~snork@cpe-75-85-45-219.socal.res.rr.com) |
| 05:25.28 | *** join/#edev JoeMoose (~snork@unaffiliated/joellama) |
| 05:29.10 | *** join/#edev JoeMoose (~snork@cpe-75-85-45-219.socal.res.rr.com) |
| 05:29.12 | *** join/#edev JoeMoose (~snork@unaffiliated/joellama) |
| 06:31.26 | *** join/#edev amarsman (~marsman@90-145-17-249.wxdsl.nl) |
| 08:31.31 | av500 | prpplague: what kind of puny fence was that anyway? |
| 08:33.07 | MonMotha | av500: the "HOA appeasing" one |
| 08:33.17 | MonMotha | aka the "As cheap as I can get away with and get them to leave me alone" model |
| 08:34.43 | *** join/#edev clio (~andrej@85.159.109.222) |
| 10:22.13 | *** join/#edev kyou (~slashbeas@funtoo/core/slashbeast) |
| 10:23.04 | *** join/#edev florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 10:23.04 | *** join/#edev florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 11:30.54 | *** join/#edev g1powermac (~g1powerma@rrcs-173-197-150-24.west.biz.rr.com) |
| 11:30.54 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 12:16.43 | *** join/#edev madsy (~madsy@ti0050a380-dhcp0547.bb.online.no) |
| 12:16.43 | *** join/#edev madsy (~madsy@fu/coder/madsy) |
| 13:04.41 | *** join/#edev jawilson (~jawilson@einstein.jeffalwilson.com) |
| 13:10.06 | *** join/#edev sunrunner20 (~jamesdoe@pool-71-97-53-7.dfw.dsl-w.verizon.net) |
| 14:20.05 | *** join/#edev orbarron (~orbarron@nat/ti/x-loizipwjofvdybcc) |
| 14:30.03 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 14:35.29 | sledges | hello |
| 14:35.52 | *** join/#edev prpplague (~danders@192.91.66.186) |
| 14:36.29 | sledges | got some freescale imx53 kicking around with fried PMICs (all Ripleys) - has anybody tried to replace/repair them? would it be easy to get a PMIC as spare, and refit it with a heat-gun ? |
| 14:37.30 | sledges | fried from overvoltage presumably (the board looks still alive (FLT and 5V come up, but flash, as it tries to draw >2A of current somewhere...) |
| 14:47.14 | *** join/#edev risca (~risca@wi-secure-7790.cc.umanitoba.ca) |
| 15:28.40 | *** join/#edev sndcrb (~sndcrb@dsl-hkibrasgw2-fef8de00-126.dhcp.inet.fi) |
| 15:42.53 | *** join/#edev amarsman (~marsman@90-145-17-249.wxdsl.nl) |
| 17:14.59 | sjhill | prpplague: ping |
| 17:15.13 | sjhill | prpplague: non-TI questions |
| 17:15.33 | prpplague | sjhill: okie dokie |
| 17:15.58 | sjhill | do you know of any sdcard switches? |
| 17:16.07 | sjhill | remote switchable |
| 17:16.30 | sjhill | so essentially |
| 17:16.41 | sjhill | i plug the switch into the sdcard slot of an embedded board |
| 17:16.43 | av500 | use a go-fer |
| 17:16.50 | sjhill | then 2 sdcards into the other side |
| 17:16.56 | prpplague | HAHAHA |
| 17:17.04 | sjhill | and be able to switch what sdcard i want remotely |
| 17:17.09 | av500 | relays? |
| 17:17.32 | prpplague | sjhill: i just finished with the first rev of the design for linaro |
| 17:17.33 | sjhill | i'm not concerned about the switching mechanism as much as trace lengths |
| 17:17.41 | prpplague | sjhill: it's off to the board shop now |
| 17:17.51 | sjhill | prpplague: no way, seriously!? |
| 17:17.51 | av500 | put the relay close |
| 17:18.20 | sjhill | prpplague: how many sdcards does it take? |
| 17:18.25 | prpplague | sjhill: basically it is a variation on this http://www.sparkfun.com/products/9237 |
| 17:18.40 | prpplague | sjhill: i have two designs actually |
| 17:19.29 | prpplague | sjhill: the first one has one side that plugs into the device(i.e. like panda), and the other side plugs into a sdcard reader |
| 17:19.37 | prpplague | sjhill: with a sd slot in the middle |
| 17:19.47 | *** join/#edev florian (~fuchs@sign-4db6b875.pool.mediaWays.net) |
| 17:19.47 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 17:19.53 | prpplague | sjhill: this way you can reprogram the sd card without having to do any swaping |
| 17:20.05 | prpplague | sjhill: the other is a two to one sd slot |
| 17:20.16 | prpplague | sjhill: with usb controls |
| 17:20.26 | av500 | no network interface? |
| 17:20.28 | calculus | I think what sjhill really wants is one of these except for sd cards, http://www.youtube.com/watch?v=H5lkxSY7QsI |
| 17:20.42 | prpplague | av500: trying to keep the first revs simple |
| 17:20.51 | prpplague | looks |
| 17:21.06 | prpplague | calculus: hehe |
| 17:21.08 | av500 | this sir, is genius! |
| 17:21.38 | sjhill | that's fantastic |
| 17:22.06 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 17:22.11 | sjhill | some archealogist is going to find that and really be confused |
| 17:23.26 | av500 | which reminds me of the PC that I once had with 3 of these installed: http://www.teac.com/DSPD/support/cdrom_drives/cdc68e.jpg |
| 17:23.41 | av500 | load it with 18 CDs and make MP3s over night |
| 17:24.03 | sjhill | slock |
| 17:24.09 | sjhill | slick even |
| 17:24.21 | av500 | I should have kept one, the mechanics inside were marvelous |
| 17:24.34 | av500 | 6cds in a stand size CDROM |
| 17:24.37 | av500 | standard* |
| 17:24.51 | sjhill | prpplague: are those designs owned by you then? |
| 17:24.56 | prpplague | yea |
| 17:25.16 | prpplague | sjhill: but we will open them up under a open source license |
| 17:25.18 | av500 | he will fight tooth and nail-paint over them |
| 17:25.21 | sjhill | prpplague: i'll by a couple from you then, hell, i'll give you a cash advance now |
| 17:25.29 | prpplague | sjhill: hehe no worries |
| 17:26.01 | sjhill | prpplague: seriously, let me know as soon as they're ready after debug |
| 17:26.02 | av500 | wonders where to install his cluster of dishwashers |
| 17:26.04 | prpplague | sjhill: which one are you interested in? the linaro are more interested in the one for use with sd card reader |
| 17:26.13 | prpplague | av500: yea just reading that |
| 17:27.01 | sjhill | prpplague: (2) linaro design, (1) 2-1 switcher |
| 17:27.34 | prpplague | sjhill: dandy |
| 17:28.18 | sjhill | prpplague: thx |
| 17:31.08 | prpplague | np |
| 17:33.11 | av500 | prpplague: why not make a networked sd card simulator? |
| 17:33.55 | prpplague | av500: could do that, just wanted to get the concepts tested and see if there is any demand |
| 17:34.51 | av500 | one that can simulate shitty class 1 cards with read errors too :) |
| 17:35.54 | *** join/#edev risca (~risca@wi-secure-7790.cc.umanitoba.ca) |
| 17:36.47 | prpplague | hehe |
| 17:48.14 | landley | slashbeast: https://lwn.net/Articles/490444/ |
| 17:50.56 | av500 | udev should rename itself into udevdecorator |
| 17:51.35 | ohsix | it's basically just to get rid of a circular dependency |
| 17:52.32 | mnemoc | mdev+devtmpfs works quite nice... but devtmpfs "misplaces" some important nodes like /dev/input/uinput :< |
| 17:54.26 | ohsix | they dont' exactly solve the same problems, but it's good some people can get by with it, and it can enable some uses |
| 17:58.09 | slashbeast | landley: do you plan to include mdev in toybox? |
| 17:59.24 | ohsix | btw, udevadm being part of udev notwithstanding, you can always write a too like it; it has a known output format and can listen for the netlink events, there's no need for a dispatcher even; you can run different program applets, or just respond to them with a script (bonus if you write a libnl binding for your scripting language of choice) |
| 17:59.27 | landley | slashbeast: yup. It's already there, just skeletal, missing stuff, and way out of date. :) |
| 17:59.43 | landley | Really it needs to be redesigned to work on top of devtmpfs. |
| 18:00.23 | slashbeast | as far as I understand devtmpfs will take care of nodes creating, right? |
| 18:00.38 | landley | Assuming devices show up belonging to root:root chmod 700 (which I think is what devtmpfs does), then mdev can just do the permission changes, drop symlinks to alternate names, and deal with firmware loading. (And deleting nodes that go away.) |
| 18:00.56 | ohsix | not without racing though :] |
| 18:01.02 | landley | slashbeast: yup. But doesn't get permissions or ownership right, and doesn't handle firmware loading. |
| 18:01.16 | landley | ohsix: the race is only for root. |
| 18:01.37 | landley | If you're already root, doesn't matter that you can access you maybe shouldn't. :) |
| 18:01.56 | landley | mdev would grant _extra_ permissions on some nodes after they showed up. |
| 18:02.08 | landley | For /dev/hda, chmod 700 root:root is pretty much right anyway. :) |
| 18:02.23 | ohsix | it's still a race, there's a window before the rename, and before the permissions are set; that only root can do it usually isn't a practical concern |
| 18:03.06 | ohsix | and probably more clever ways to do something with it than i can think of |
| 18:06.57 | landley | ohsix: why would I rename any of them? The kernel suggests a name, if I want another name I create a symlink. |
| 18:07.18 | ohsix | right |
| 18:07.35 | landley | ohsix: if you mount a tmpfs somewhere, and just leave it alone, nobody but root should ever be able to access anything that shows up in it. |
| 18:07.41 | landley | If you can manage to exploit that, we've already lost. |
| 18:07.46 | landley | So what race are you talking about? |
| 18:08.21 | ohsix | you don't always have an exploit that gets you a root shell |
| 18:08.33 | ohsix | often you have to take a detour to take advantage of something clever someone overlooked |
| 18:08.33 | landley | ohsix: define "exploit". |
| 18:08.52 | ohsix | i thought i was expounding on your use of the word |
| 18:09.02 | landley | Files you can't access show up. You can pretty much list their names, but you can already cat /proc/modules and look at sysfs and such anyway. |
| 18:09.08 | landley | No, you said "not without racing though". |
| 18:09.49 | landley | How does mdev on top of devtmpfs coming along afterwards and adding permissions and extra names to files (and doing firmware loading for devices that show up that _didn't_ create a /dev entry yet) have interesting races? |
| 18:09.52 | ohsix | that was a red herring, not in the sense that i stated it; but that it's circumstantial and i'm not clever enough to speculate, but they are always opportunities |
| 18:10.07 | landley | ohsix: not in this instance, captain. |
| 18:10.13 | av500 | pmi, what is in devtmpfs that was not in devfs? |
| 18:10.33 | ohsix | do you know how to ask git for just recent renames? |
| 18:10.35 | landley | av500: wrong way around. |
| 18:10.46 | landley | devtmpfs does a small, sane set of things. |
| 18:10.52 | ohsix | glagh |
| 18:11.00 | landley | devfs did a giant unbounded blob of horrible crap that should never have been in the kernel. |
| 18:11.22 | ohsix | i take it you weren't in on the great bikeshed naming event, or were indifferent |
| 18:11.33 | landley | The _fundamental_ problem with devfs was it tried to figure out what user and group each device should belong to, which meant the kernel had to know what was in /etc/passwd to know what users there were, which is NOT THE KERNEL'S JOB. |
| 18:11.43 | av500 | ic |
| 18:12.06 | av500 | /etc/passwd migtt not even exist |
| 18:12.12 | landley | Beyond that it tried to provide solaris-style names for things, which were ugly and broke stuff and had subdirectories (and creating/removing subdirectories and their contents is racy). |
| 18:12.20 | ohsix | people might take issue at where you draw the line on what the kernel is supposed to do, but in that case you are correct; the other side of the debate with devtempfs was the naming policy period |
| 18:12.45 | landley | av500: the kernel knows about uid and gid. To the kernel, each is just a number, and the interesting thing is whether or not they match. |
| 18:12.51 | landley | THe only special one is uid 0: root. |
| 18:13.20 | landley | But devfs had to figure out who each thing belonged to, which is something the kernel is fundamentally ill-equipped to do because what users this system has is policy. NOt the kernel's job. |
| 18:13.38 | landley | ohsix: naming policy is inherent to sysfs. |
| 18:13.57 | landley | Each device has its own subdirectory in sysfs. Those directory names have to be unique. |
| 18:14.03 | ohsix | is it? they're properties of what's actually in the system, and their relations |
| 18:14.18 | landley | All devtmpfs did was use those existing directory names as the device names. (Same as mdev started doing in 2005.) |
| 18:14.20 | ohsix | they have to be unique, but you aren't typically picking them in a driver you write |
| 18:14.32 | landley | ohsix: modules need unique names too. |
| 18:14.40 | landley | And yes, you are picking them in the driver you write. |
| 18:14.57 | landley | The driver exports named resources. |
| 18:14.58 | ohsix | and they only have to be unique insofar that you wouldn't be looking for a nonpci part under the pci bus tree, but if you have a pci part you wouldn't even be talking to sysfs, it is done for you |
| 18:15.22 | landley | Lots of drivers do this. i2c does this, network interfaces do this... |
| 18:15.23 | ohsix | the kernel namespace is the kernels business |
| 18:15.49 | landley | ohsix: sysfs is just a view into the kobjects data structures. |
| 18:15.55 | ohsix | userspace has little want or care, it's not resolving symbols from userspace in the kernel, and doing stuff with them |
| 18:15.55 | landley | There are OLS papers on this. |
| 18:16.07 | ohsix | i know that |
| 18:16.17 | landley | ohsix: the kernel namespace already has to be unique, and already needs names for these things. |
| 18:16.24 | landley | devtmpfs just exports that kernel namespace where userspace can see it. |
| 18:16.43 | ohsix | you aren't trying to satisfy the set of user + kernel uniqueness, that's just the kernel's namespace |
| 18:16.50 | landley | Some people flip out about this. I cordially invite them to launch themselves into deap space without an air tank. |
| 18:16.55 | landley | THey are not my problem. |
| 18:17.04 | ohsix | right, which is why i understand your position |
| 18:17.09 | landley | ohsix: usernames are a different namespace from device names. |
| 18:17.16 | landley | You can have a /dev/bin and a user named "bin" and those are different things. |
| 18:17.19 | ohsix | but there are people with other ideas about it, and you can't cooperate with them |
| 18:17.26 | landley | THe kernel doesn't use usernames. It uses user id's. |
| 18:17.37 | landley | THe problem is, other than root, the kernel doesn't know what any of those users DO. Nor should it. |
| 18:17.48 | ohsix | are you arguing against devfs? i don't understand the digression |
| 18:18.03 | landley | The _other_ problem with devfs is we didn't have sysfs yet. So when you plug in a USB device you haven't loaded a driver for yet... what do you do? |
| 18:18.15 | av500 | yes, i threw devfs into the ring :) |
| 18:18.16 | ohsix | you write udev |
| 18:18.17 | landley | devfs was trying to notify people about hardware showing up before the driver was loaded, but the drivers are what create /dev nodes. |
| 18:18.34 | landley | /dev/zero does not correspond to specific hardware. /dev/hda1 and /dev/hda2 and /dev/hda3 are different views to the same piece of hardware. |
| 18:18.45 | landley | ohsix: I don't write udev, I wrote mdev. |
| 18:18.53 | ohsix | information from /sys isn't the only type of information udev stores about a device |
| 18:18.56 | landley | udev is an overcomplicated pile of unnecessary complexity. |
| 18:19.07 | ohsix | i'm telling you what they did, you said "what do you do" |
| 18:19.19 | landley | What "they" did was stupid, and I argued with them about it for years. |
| 18:19.45 | landley | There's a reason udev needed to be replaced every time you installed a new kernel for about 7 years there. They got the _design_ wrong. |
| 18:20.02 | ohsix | udev just applies rules to uevents, takes a little bit from /sys and what else it can get from its helpers, and allows userspace to enumerate those properties it added; and know when devices come around on a useful lifecycle |
| 18:20.31 | ohsix | does mdev use the output of the udev work? the kobject uevents and other facilities? |
| 18:20.38 | ohsix | s/output/product |
| 18:21.07 | landley | Of course not. THat's like saying "does busybox grep use the output of gnu grep". |
| 18:21.17 | landley | mdev is a much simpler tool that does the interesting bits of what udev does. |
| 18:21.29 | ohsix | then where does it source events to actually work |
| 18:21.38 | landley | ANd then devtmpfs came along and did about half of what mdev did, but it turns out to be the _interesting_ half for a lot of embedded systems. |
| 18:22.02 | landley | ohsix: sysfs with /sbin/hotplug notifications. |
| 18:22.36 | ohsix | did it exist before there was a sysfs? |
| 18:22.37 | mnemoc | and `mdev -s` is sloooooooooooow :) |
| 18:22.44 | landley | echo "/sbin/mdev > /proc/sys/kernel/hotplug" to enable notifications. |
| 18:22.51 | landley | mnemoc: it didn't used to be. Busybox has gotten bloated. |
| 18:23.18 | landley | I was proud that mdev -s finished in under a second on my 200 mhz test system. |
| 18:23.28 | mnemoc | :o |
| 18:23.52 | ohsix | well i can't make the argument i would have based on the answer that isn't yet forthcoming, i have to go anyways |
| 18:24.14 | ohsix | but if no, where did it get the information to work; and if yes, you benefitted from the work :] |
| 18:25.09 | landley | ohsix: http://lists.busybox.net/pipermail/busybox/2005-December/051272.html |
| 18:26.46 | ohsix | thanks, will check it out when i get home; i was under the impression some random terd was behind mdev btw; when it creeped up again not too long ago, i understand the use for it, but not proposing it as a replacement, or a better than udev type thing; they're not comparable at least as i know them now |
| 18:33.14 | *** join/#edev risca (~risca@wi-secure-7790.cc.umanitoba.ca) |
| 18:34.30 | landley | ohsix: mdev happened after I wrote a shell script to scrape /sys and populate /dev with block and char devices. |
| 18:34.52 | landley | I posted the shell script to linux-kernel (it was slow, but meant I didn't need a static /dev), and Frank Sorensen did a much much faster C version. |
| 18:35.20 | landley | And then solar@gentoo and I started speculating about a config file format for it (to deal with ownership and permissions) on #uclibc channel... |
| 18:36.21 | landley | ohsix: Ha, the internet never forgets: http://ibot.rikers.org/%23uclibc/20051108.html.gz |
| 18:40.26 | landley | I note that mdev has changed a lot since I left busybox in 2006, and I haven't really paid close attention. |
| 18:41.05 | landley | The "mdev -s" without a config file behavior is basically what devtmpfs creates, and that's pretty much what I was using in my little embedded systems, so I haven't looked at what they've done recently. |
| 18:41.10 | landley | Slowed it way the heck down, from what I can tell... |
| 19:02.09 | *** join/#edev dijenerate (~dijenerat@173.225.251.175) |
| 19:03.22 | *** join/#edev uwe_ (~uwe_@dslb-088-066-186-052.pools.arcor-ip.net) |
| 19:09.26 | *** join/#edev bsdfox (~h36sa@c-76-20-20-210.hsd1.ca.comcast.net) |
| 19:09.26 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 19:57.42 | *** join/#edev gandhijee_ (~akp@50.12.169.99) |
| 20:23.41 | *** join/#edev risca (~risca@wi-secure-7790.cc.umanitoba.ca) |
| 20:40.00 | *** join/#edev TimH (~TimH@nat/ti/x-frfmguskubctenxx) |
| 22:07.16 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
