=== robr__ is now known as robr === asac_ is now known as asac [08:07] good morning [08:13] morning === dholbach_ is now known as dholbach [13:29] Is pbuilder the standard build for UME? === doko_ is now known as doko [14:19] InSearchOf: You can use pbuilder, but the build is based on a (probably modified) sbuild and scheduled by Soyuz (Launchpad) === cprov is now known as cprov-lunch [14:32] lool, alright.. I'm going to be setting up everything tonight... where can I get docs on sbuild? or is it pretty much the same as pbuild. [14:32] on my local dev server that is [14:38] InSearchOf: You might want to have a look at the sbuild and schroot packages; then google for wanna-build; there aren't many docs, but there are some on debian.org I think [14:39] InSearchOf: But I don't know what your efforts will be for [14:40] lool, what do you mean? [14:41] InSearchOf: Well you're free to setup what you want, but I don't think you have any guarantee that your archive / builds end up with an ubuntu.com label on them: I'd personally guess that to be ports.ubuntu.com packages, the buildds have to be run in canonical/ubuntu infrastructure [14:43] InSearchOf: Also, the whole ubuntu.com builds are currently scheduled by a central piece of infrastructure which you don't have access to; the data is publicly available (the list of source packages / versions), but you'd have to reinvent the wheel to hook into them (to get the list of what sources you need to build for example) [14:44] lool, ahh... well maybe I will take a different approach... thanks for the heads up [14:44] InSearchOf: There are thousands of packages to build and to give back and to host etc.; it's a big task [14:44] InSearchOf: But then I don't know what your goal is [14:44] lool, my main goal was to understand how UME functions [14:44] If your goal is to take the source packages from ubuntu.com and build them for your target hardware, that's fine; you might want to select a subset of the archive naturally [14:45] InSearchOf: UME functions mostly like Ubuntu functions [14:45] Except for the image builds which are made with a different tool [14:45] InSearchOf: We upload source packages to the archive, and these source packages are the same as for other arches [14:45] lool, I just want to be a step ahead of the game if the project gets approved [14:45] InSearchOf: More clearly: glibc is uploaded once and built for all arches [14:45] It's the same source [14:46] lool, that is exactly how pdaXrom's builder works [14:46] InSearchOf: If your goal is that UME ends up producing ARM packages / images, then perhaps you should explain this on a public list with key audience and explain what you would bring into the project to make it happen (obvisouly adding an arch has a cost for the current infrastructure / team) [14:47] InSearchOf: Right, but since we're using the same central architecture for UME + Ubuntu for most things, we're not going to change to pdaXrom just for ARM [14:47] Actually the whole architecture works for ARM as well, it's just not done at the moment [14:48] lool, no I wasnt trying to convert anyone... I was just stating the fact [14:48] InSearchOf: Ok; well "pbuilder" can build from source for ARM too [14:49] But we're only using pbuilder on end-developer systems; it's handy to setup, but it's not made to interact with an archive as large as the one we have [14:50] InSearchOf: I also have to mention there is already a quite large ARM effort on Debian's front: there are 3 arm architectures: arm, armeb and armel [14:50] agreed, Would the mailing list be a place for me to state my proposal? [14:50] arm is an official Debian arch; armel is pending inclusion and was rebuilt at gnuab [14:50] For Ubuntu, we could start from such an arch to bootstrap the Ubuntu armel arch [14:51] InSearchOf: Depends of the proposal you want to make: if it's about adding an arch, then ubuntu-devel or devel-discuss might or might not be better suited than -mobile; not sure [14:51] lool, it seems like I dont have a very good chance at getting this to pass though the board [14:52] InSearchOf: I think arm is much desired, but I want to make you aware of the fact that it represents an important effort on the Ubuntu side of things to add an arch like we have ia64/powerpc etc. and it has many requirements to happen [14:53] InSearchOf: It's likely that adding an architecture represent a concrete cost in human resources and in hardware etc.; things which you might be able to offer or not [14:53] lool, agreed... but I'm determined so I'm going to try my best to state my claim and make this worth while to everyone [14:54] InSearchOf: For example, you don't know about the current build infrastructure; I don't know whether it's possible that for example your team runs the buildds for Ubuntu, but if you say that you offer the hardware and some buildd maintainer time for a year, perhaps you'll make your proposal more appealing than if you say "please buy some hardware and spend some time to build an arm flavor" [14:55] InSearchOf: Certainly discussing it is the important part of it :) [14:55] InSearchOf: Simply: do know that the cost can be quite high for Ubuntu and/or Canonical [14:57] lool, I understand that, and yes we have servers located in 3 places in the world. I can do my builds on a local box with out the need of ubuntu to host it. BUT, if there is a requirement for it to be hosted by Canocial or Ubuntu, then I really wont have a choice [14:58] InSearchOf: Ok; so perhaps explain that you want Ubuntu ARM .debs (or "armel"), and that you can offer hardware, and optionally hosting [14:59] InSearchOf: Did you try using Debian's arm .debs? Is this what you're looking for, but with Ubuntu sources instead? [15:02] lool, currently we build *.ipk, our OS isn't debian based at all... [15:02] if we would build in deb support we the apps would most likely run. [15:03] We build armv5tel which is optimized for the pxa270... but standard arm packages will run [15:03] InSearchOf: Well you need to check which CPU requirements this means, what software versions are available etc. I guess [15:05] lool, alright I will look into that. [15:06] Well just a suggestion [15:06] But adding an arch is such a big task that this is really important to get right [15:06] lool, any other hints that might help me get in the door? [15:07] Give as much detail as possible on what your big picture goal is and technical details of your constraints :) [15:09] lool, I'm going to be buggin you everyday :-) j/k [15:09] Heh [15:09] But you're the first person backing the desire for ARM with something more concrete like hardware [15:10] We had many requests for it, but nobody wanting to sponsor it at some level [15:10] Dunno whether your sponsoring will be sufficient, it's certainly worth trying ;) [15:10] Well, I'm here to get it done... I would like to actually expand outside of the Zaurus market into other ARM based devices [15:32] i am sure you know this already but i did not understand arm to well until i kept this 'cheat sheet' with me: [15:32] ARM = the old ARM [15:32] ARMEL = ARM + EABI + Little Endian [15:32] ARMEB = ARM + EABI + Big Endian [15:32] EABI is the new ARM Embbeded ABI [15:32] and ABI is: http://en.wikipedia.org/wiki/Application_binary_interface [15:34] http://wiki.debian.org/ArmEabiPort [15:34] I think the important data apart of endianess is the version of the ARM architecture / CPU instructions which is being allowed and the floating point implementation [15:35] At the moment, floating point is extremely expensive and only very old ARM instructions are allowed IIRC [15:38] IIRC armel is the most widely used (at least recently) so it probably makes sense to target that [15:41] Yes, armeb is quite less common; the slug is one notable user, but it can do both === cprov-lunch is now known as cprov [15:50] I like ARM. As smagoun once said, there's a cure for that but what the heck :) [15:50] armel + eabi + a decent L2 cache on the chip goes a long way toward fixing ARM... [15:51] smagoun: isn't that what everybody uses :-p [15:52] amitk__: I wish! We did development on the old ABI with the PXA270. That meant WMMX was off-limits, and the 32KB cache didn't get along well with Mozilla [15:52] it wasn't pretty [15:54] smagoun: think about it this way. You can tell your kids you actually did programming on a single core ARM processor with 32KB cache ;) [15:54] that, and the 6502... [15:54] cache is for sissies... [15:55] agoliveira: I don't think the Mozilla devs like being called sissies :) [15:56] * agoliveira did a lot assembly for 6502, z80 and the lot [15:56] agoliveira: I imagine you mess with the instruction pipelines directly.... [15:58] amitk__: Those were the days, self-modifing code, a bit of forth too. :) [16:01] I collected a proposed agenda or list of topics at https://wiki.ubuntu.com/MobileAndEmbedded/UsbClientMeeting [16:02] lool: I suggest considering MTP [16:03] suihkulokki: Right, will mentoin PTP too, thanks [16:03] I'm not sure if it's the right choice, but the alternatives suck too.. [16:04] Argh, wrong level [16:04] suihkulokki: Well I'm clearly unhappy with the mass storage proposal; I wouldn't mind doing a bunch of things over IP though [16:05] But PTP is fairly common, so MTP sounds plausible -- dunno how widespread that is [16:05] lool: windows media player does that [16:05] suihkulokki: Do you know about licensing / I.P. issues with MTP? [16:06] nope, but it's pretty trivial stuff [16:06] (unless you do the DRM thing) [16:07] suihkulokki: Quite interesting then [16:08] RNDIS seemed to be problematic because of Microsoft intellectual property at some level [16:09] but don't trust me on IPR, IANAL etc [16:09] agoliveira, smagoun, amitk__, suihkulokki: feel free to complete the wiki page; before the meeting next hour [16:09] suihkulokki: "You're the one who told us!" [16:09] lool: Sorry, I don't have what to add as I'm not very familiar with the issue but in a higher level. [16:10] agoliveira: Just reviewing it was nice already; thanks === lool changed the topic of #ubuntu-mobile to: USB Client Meeting 1700 - 1800 UTC https://wiki.ubuntu.com/MobileAndEmbedded/UsbClientMeeting | https://wiki.ubuntu.com/MobileAndEmbedded | https://wiki.ubuntu.com/MobileAndEmbedded/FAQ [16:13] * agoliveira frightens by the perspective of using mass storage with vfat [16:13] I feel it's fragile to mount/umount stuff and use it from Windows and then Linux [16:14] And it's obviously restrictive [16:16] If the system could boot quickly (<10sec) we could simply shut down the OS then boot into a client-only mode when connected to the PC. iPod does this. When the user's done, they unplug + the system quickly comes back up in UME. [16:17] smagoun: Perhaps this makes sense on the wiki page? [16:17] I'll leave it up to you to list it there or to mention it during the meeting [16:17] lool: possibly. The 10sec boot is a bit of a fantasy, sadly [16:18] It would seem less fragile to me like you describe, but it's a different drawback instead [16:18] We would trade reliability for reboots [16:19] I feel the IP based solutions are vastly superior because they can all work at the same time and the device can still be used normally [16:19] might not be a bad tradeoff... [16:19] it's not like syncing/file sharing is inherently reliable as it is... [16:20] smagoun: I concur; especially since I don't expect many app to handle a new UME specific DBus message "UME has detected an USB cable connection; please save yourself and shut yourself down" while handling shutdown is to be expected [16:20] exactly [16:22] What's the right channel for asking questions about Firefox on Ubuntu? I'm trying to package a FF extension, but I'm not having much luck. #distro? #ubuntu-devel? [16:22] smagoun: Dunno the channel but the right person is asac :) [16:23] asac: ^^^ [16:23] smagoun: #ubuntu-mozillateam [16:24] asac: thz [16:24] thx [16:24] * ian_brasil hopes smagoun is doing this for the midbrowser [16:25] ian_brasil: yup - grab and drag extension [16:33] smagoun: Well, I had this idea of an "a la Apple" approach: one can't simply copy files on and off the device but has to use a client application for that. THis approach would have a few advantages like standarize access and make on the fly conversion of file formats thus we would not have to worry with codecs and file formats support. The client would do that on the desktop. The problem is that we would have to write this applica [16:34] This is the way ipod/iphone works and I don't see people complaining about it. [16:34] agoliveira: That client application would have to be a windows app. You want to write it? I don't. :) [16:34] smagoun: I don't see a problem with that and yes, I would write it. [16:34] rob__: ping [16:35] rustyl: ping [16:35] agoliveira: I think it's a safe approach, I just don't want to deal with Windows or supporting a client app. You should add it to the meeting agenda. [16:43] agoliveira: On what layer would your application run? [16:43] I think it's nice to use PTP as it would simply trigger the proper app on most computers [16:44] "File sharing" protocols are capable of what we need, but then we're showing up technical bits (files) to the end user which we might want to avoid [16:44] lool: That's an idea. PTP could trigger the application that would take care of the files, sync and format conversion. [16:44] k [16:44] wiki.ubuntu.com is sloooooow today... [16:46] lool, regarding to PTP, do you know any existing Linux gadget driver for that? [16:47] alek_desktop: I don't know about them [16:48] lool, another question, does PTP support any other media file beside pics? [16:49] alek_desktop: suihkulokki mentionned MTP which is an extensoin for other media files [16:51] lool, well. need to look it up. thanks. [16:53] alek_desktop: There's something called gadgetfs and the page at http://tali.admingilde.org/linux-docbook/gadget/ch02.html says "file system (for PTP gadgets)" [16:53] Dunno whether this is the driver [16:53] I'd guess this is a host mode driver; right now most apps are based on gphoto which uses libisb directly [16:54] It seems many people would want something like this though :) [16:56] agoliveira: I'm not sure why you mention "completely different approach" on the wiki in a separate section but you say you would use PTP === robr__ is now known as robr [16:57] lool: I meant by that adding a different layer to the user. In this case the access method does not matter. [16:57] Sorry, poor choice of words. [16:58] lool: Edit it out if you want please. [16:58] smagoun: "Reboot in client mode" do you consider this specific to mass storage implementation? If it's orthogonal, perhaps it should be in "implementation"? just a thought [16:59] hey, rustyl_ and bspencer [16:59] alek_desktop, hows it going [16:59] hi guys [16:59] alek_desktop, morning [16:59] well, we just start to talk :-) [16:59] rustyl_, bspencer, How's CHina, guys? [16:59] agoliveira, we are back now [16:59] morning, guys [16:59] agoliveira, hello. We're back in the states now [16:59] but China was great. [16:59] lool: it's not necessarily mass-storage specific [16:59] I envy you, I aways wanted to be there. [17:00] a little smoggy... but a nice visit and a cool city [17:00] bspencer, it's Intel's meeting do you want to run Mootbot? [17:00] smagoun: (I agree; in fact it could work with whatever layer, so it's not really in the choice of layer I guess) [17:00] smagoun: ipod touch and iphone no longer provide direct mass storage access afaik [17:01] bspencer, it will make it a bit easier to keep notes from the meeting I think. [17:01] (Thanks everybody from Intel for making it to the meeting! It's quite early or late where you live) [17:01] davidm, sure... I haven't been paying attention to how though :) [17:01] MootBot, activate. [17:02] bspencer, #startmeeting [17:02] #startmeeting [17:02] Meeting started at 17:02. The chair is bspencer. [17:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:02] rock [17:02] I'm not the organizer, but I'll keep notes [17:02] my ipod acts as a mass-storage device [17:02] bspencer: Bob has thah powah! [17:02] rusty, alek_desktop do you want to drive? [17:02] and my iphone [17:02] bspencer, you might want to set [topic] [17:03] [topic] USB Client for MID [17:03] New Topic: USB Client for MID [17:03] ? [17:03] hmm... [17:03] I'm here [17:03] well... we started going down a path for moblin [17:03] and the path we choose for moblin was a very simple, mass-storage specific path [17:04] lool sent out an outline/agenda ... but first i think we should have rusty give an overview of the moblin solution [17:04] where we have to coordinate access to a vfat partition [17:04] ok [17:04] [ "Agenda" is in the topic ] [17:04] * rustyl_ looks at the agenda [17:04] [link] https://wiki.ubuntu.com/MobileAndEmbedded/UsbClientMeeting [17:04] LINK received: https://wiki.ubuntu.com/MobileAndEmbedded/UsbClientMeeting [17:04] (It's more a list of things we don't want to forget to discuss than an agenda) [17:06] rob, which name is "real" rob ? [17:06] alek_desktop: they're all me -- just restoring one of my systems [17:06] the reality is that there are a numerous possible solutions, and a given customer will likely choose what ever makes sense for their product [17:07] rustyl, why do you want to give access to vfat, eext3 has always been the spec not vfat [17:07] i really wanted a very simple solution on moblin.org to help proof the usb client gadget drivers [17:07] Are you thinking of external flashs not the internal space? [17:07] lool, can you define PTP and MTP when we get to it? [17:07] let me layout the simple plans we were thinking [17:08] ok, so one possible solution: [17:08] HappyCamp: I think it's best you checkout the wikipedia page -- it's where I learnt about them myself [17:08] HappyCamp: PTP is what many cameras and even the iPhone use when transferring photos to your photo application [17:08] we actually use a vfat partition on disk to host all user data (media files, media database, cal database, etc.) [17:08] HappyCamp: I understand it's directly over USB [17:08] MTP is a generalization [17:08] we coordinate via hotplug scripts access to the partitions [17:09] and specifically lock out the user from using the device while in 'sync mode' [17:09] and when we unplug then we remount the vfat partion and open the gates [17:09] rustyl_: Where's the partition exactly? /home? /home/ume? /home/ume/Documents? [17:09] so... that's just one solution [17:09] lool, my idea was to choose a location and then document it via a gconf entry [17:09] lool, thanks [17:10] so the media app wouldn't hard code any specific path, but just read the path from a gconf entry (and use a hard coded default if the gconf entry isn't there) [17:10] Err where would your GConf db be? in /home/ume/.gconfd? :) [17:11] (.gconf not .gconfd) [17:11] isn't there a system wide entry? [17:11] There are mandatory settings and default settings, but no system wide DB [17:11] The DB is per user [17:11] ok, so not gconf [17:12] but that's the basic idea... not much to it [17:12] [idea] vfat partition on MID hosts media files, media database, etc. Hotplug scripts used to access partition. PC has access to mounted drive exposing vfat partition. [17:12] IDEA received: vfat partition on MID hosts media files, media database, etc. Hotplug scripts used to access partition. PC has access to mounted drive exposing vfat partition. [17:12] The design is very different if only apps accessing Documents/ need to be closed, or all aps accessing $HOME [17:12] only apps accessing something like Documents [17:13] Sorry to interrupt; I think you were still in the middle of presenting the current moblin solution [17:13] lool, we put the gconf schemas under /etc/gconf/gconf.xml.defaults [17:13] rustyl_: presumably you have looked at how VFAT will work over NAND flash? [17:14] rustyl_: in terms of wear-levelling, that is. [17:14] there are details of course, but the idea is that the hotplug script would signal applications that use this personal storage to close open files, and then the script would unmount the device (and if it had to then kill the apps) before exposing the device to the host pc over usb [17:14] alek_desktop: What's the point of using GConf? For which user would you start a gconfd? What if the data has been overriden in ~/.gconf and it's not mounted? [17:14] alek_desktop: I don't think GConf makes sense [17:15] amitk__, so far all the design wins i have seen have hardware that stands between the os and the flash, and the hardware makes the device look like a regular drive (i.e. handling wear leveling and the rest) [17:16] lool, the idea is that we have some kind of configuration that points to the mount. If gconf doesn't work then we use something else [17:16] rustyl_: Why did you decide to follow the mass storage path? [17:16] rustyl, so you are suggesting that all apps that use storage have to be revised to know what to do when signaled? [17:16] rustyl_: (ack) [17:16] lool, the Gconf existing in this solution only means the mount point is configurable. [17:16] don't we lose a lot of robustness putting media on a vfat partition rather than ext3? [17:16] i think the network access is pretty darn complicated, and i need to proof something now [17:17] alek_desktop: Ack; I'm just pointing out GConf is not what you're looking for here [17:17] rustyl_: Are you building a proof of concept or something that's suitable for a product? [17:17] patm: +1 the problem is windows having to read the files. [17:17] the design I have has a 2G drive, do I need to permanently allocate disk just for the vfat partition as well? [17:17] rustyl_, so you are suggesting that all apps that use storage have to be revised to know what to do when signaled? [17:18] rustyl_: Since we're talking of ultra mobile devices, I thought that perhaps you'd have a solution for sharing ofer wifi -- did you settle on one? [17:18] agoliveira, I understand, this is not a practical solution [17:18] i think it would be suitable for product, but my point is that we are not dictating what every possible vender might or might not build. We do need to give simple access over USB to app data [17:19] rustyl_: Do you need it over wifi as well? [17:19] Isn't wifi more mobile and user friendly than e.g. plugging a USB cable? [17:19] lool, i don't have any requirements to provide access of wifi, but that would be cool. I do not know what your customer is demanding [17:20] i think the issue is that you can not assume everyone has wifi [17:20] rustyl_: I'm sorry if I ask a very naive question, but who's setting your requirements for USB cable access and not wifi? [17:20] Is this internal to Intel? [17:20] I think on an internet device you can assume network access [17:21] yes, i do have internal requirements [17:21] The USB client PRD states that file access over wifi is too complicated for users [17:21] basically... enable the hardware. We have this usb client hardware, so use it [17:21] they only think it is used for internet [17:21] and the most CE devices are using USB as sync way I think. [17:22] btw, wifi cameras use PTP over ip for transferring pics [17:22] This is much less of a slave to PC type of device than those using usb client [17:22] i guess i still buy the cheap cameras [17:22] suihkulokki: Wow [17:22] suihkulokki: mdns to locate them? [17:23] lool: I'm not sure [17:23] all, keep in mind that any sort of network access introduces some security requirements that aren't present for a direct (USB) connection [17:24] smagoun, correct. [17:24] rustyl_, Two questions that I think are important, 1) You are suggesting that all apps that use storage have to be revised to know what to do when signaled? So if a user is viewing a video clip and plugs in the USB it's OK to terminate what they are watching under them? 2) Their is an assumption that the internal storage will be partitioned off into OS and data storage and data storage will be VFAT? [17:25] 1. all apps that are storing files that they wish to sync [17:25] 2. yes, we actually partition vfat [17:26] if we partition the device or use a file is open, but that was the idea [17:26] ok, that's one path... did we want to iterate over the other possible paths? [17:26] Unless we use a "client mode" when the sync/file transfer is activated or something of the sorts [17:27] we were going to put the device in something like 'sync mode', opening a full screen window blocking access to the device from the user [17:27] rustyl_: So what about PTP? [17:27] somebody describe it [17:27] rustyl_: That's the idea. [17:28] rustyl_: Protocol implemented by many cameras to exchange photos with the PC [17:28] rustyl_: And its friend MTP which is an extension for other medias [17:28] i mean... how does the entire picture look [17:28] does that mean we have an application running on the host device? [17:29] rustyl_: I guess kernel driver implements PTP device emulation and is hooked to some userspace program similar to gphoto programs, but sharing photos instead of retrieving them [17:29] to open the other end of the ptp connection? or is there some standard service that already exists on pc's [17:29] kernel side is probably optional since gphoto currently speaks PTP with cameras [17:30] somebody remind me what MTP is [17:30] Media Transfer Protocol??? [17:30] rustyl_: 18:28 < lool> rustyl_: And its friend MTP which is an extension for other medias [17:30] rustyl_: Microsoft extension to PTP to handle other media types than just photos [17:30] http://en.wikipedia.org/wiki/Media_Transfer_Protocol [17:30] LINK received: http://en.wikipedia.org/wiki/Media_Transfer_Protocol [17:31] oh... i thought ptp was just point-to-point :-> [17:31] Picture Transfer Protocol [17:31] rustyl_: No, it's like what the iPhone is doing (only if you did take some photos) or what your camera is doing if it's not only mass storage [17:32] My Canon cameras do this for example [17:33] * rustyl_ notices the wikipedia ref to potentially new USB class [17:33] You can also see it's widely implemented in hardware devices so it's expected to be supported by the OS [17:33] e.g. OSX simply starts iPhoto when I plug the iPhone with photos (and iTunes for other stuff) [17:35] would we need to implement a different gadget driver, or could we do this in user space (on the device)? [17:35] rustyl_: So I guess PTP wasn't explored at Intel ATM? It seems like a solution based on this doesn't require vfat and can be used "live" [17:35] lool, it does look promising [17:35] rustyl_: Didn't investigate whether we need a driver, Alek started some research and I googled too, and couldn't find one [17:36] rustyl_: I think libgphoto2 is in userspace [17:36] lool, seems no Linux gadget driver implementation available yet [17:36] libgphoto2 is user space... are you saying it implements ptp? [17:36] It's using libusb [17:36] http://www.linux-usb.org/gadget [17:36] LINK received: http://www.linux-usb.org/gadget [17:36] I mean it's a full user space implementation [17:36] You don't need an USB PTP driver to use libgphoto2 [17:37] Sorry, wasn't very clear [17:37] lool, bug libgphoto2 works on host connections.... has anyone ever done this on the client side? [17:37] rustyl_: I don't know about it and couldn't find such an implementation in some minutes research [17:37] But found people looking for one :) [17:38] ok, so ptp/mtp looks promising, but needs some more investigation [17:38] to fully understand how a solution will work [17:38] Ok; there was also proposal to do IP over USB; I suppose this is mostly RNDIS, dunno whether alternatives exist [17:38] [idea] Use PTP/MTP to transfer data over USB connection. Needs more investigation. [17:38] IDEA received: Use PTP/MTP to transfer data over USB connection. Needs more investigation. [17:38] are there any additional security conserns (just thinking out loud) [17:39] i'm guessing not since this isn't something we do over the network [17:39] rustyl_: You mean in the IP over USB case? [17:39] and if it has any security checks then its more the a vfat/mass-storage solution [17:40] i was talking about the PTP/MTP... just trying to think of more gotcha's, but that can be done in the investigation [17:40] vfat looks like zero access control to me; if you want to do access control, then I wonder over which protocol we would do this [17:40] it is zero access control [17:40] rustyl, for last idea (vfat), we could create software on the PC that mounts the ext3 partition and translates it to a filesystem view for users. [17:41] then we wouldn't have to deal with a fixed-size, no-security, non-journaling vfat partition. (brainstorming) [17:41] bspencer: I think there's an ext3 browser under Windows [17:41] lool, yes, I've seen that. open source? [17:41] bspencer, better idea, a linux driver that promotes ext3 as vfat so you don't need anything on the Windows machine. [17:41] bspencer: Yes [17:41] bspencer: we can do the fat<-->ext3 translation on the device [17:41] bspencer: I've seen at least one opensource one [17:42] ok, but we are not talking about the traditional mass-storage device gadget driver, but something that can share access to the device without corrumpting the filesystem [17:42] that's the key... mass-storage that can share access [17:42] rustyl_: Not necessarily, we could reboot into a share-only mode as smagoun proposed [17:43] lool: Rebooting is costly [17:43] With a translation layer, we might be able to do concurrent accesses [17:43] sure... so that's kind of in-line with the vfat solution [17:43] but IF we could share then that would really simplify things [17:43] Right, PC side ext3 support suffers from the same issues as vfat [17:43] but maybe it's not really feasible [17:43] Except it doesn't impose cutting space in two [17:44] it simplifies partitioning [17:44] even if we force apps to shutdown when syncing, having no vfat on MID is desireable, if possible [17:44] rustyl_: The open-source emulator QEMU includes code that presents a folder to the emulated environment as a VFAT device. [17:45] but it suffers from needing software on the host that is not allways there (i.e. i don't think out of the box OSX and WinBlows can mount extanything) [17:45] smagoun, fat--ext3. Can you find some pointers [17:45] rustyl_: I think OSX can do ext3 [17:45] really? [17:45] lool: I don't think so [17:45] I think I plugged an USB key with ext3 at some point [17:46] it's hard to tell with OSX since it hides all the low level stuff from the user [17:46] I should check that [17:46] Anyway windows doesn't, so the question is m00t [17:46] rustyl_, simplifying partitioning is important when dealing with small devices, and not killing applications with open files is also important. [17:46] bspencer: qemu is here: http://fabrice.bellard.free.fr/qemu/ I'm trying to find decent docs on the vfat<->ext layer/features [17:47] let's do capture the idea said earlier... boot into sync mode that shares the entire ext filesystem [17:47] davidm, but I think the latter is less important -- if the user plugs in, we can prompt (do you want to sync now and kill apps? yes/no) [17:47] smagoun: the virtual vfat thing in qemu is buggy like hell [17:47] [idea] boot into sync mode that shares the entire ext filesystem [17:47] IDEA received: boot into sync mode that shares the entire ext filesystem [17:47] rustyl_: we don't want to share the entire ext filesystem in any case - we only want to share a subset (/home/ume/Documents, for example) [17:48] suihkulokki: really? I've never had trouble with it (though I don't use it on a daily basis) [17:48] smagoun: which is no suprise, since a OS mounting a vfat partition does not expect blocks getting changed underneath [17:48] Not trivial to share the ext3 in single user mode or something as we need some running linux kernel sharing the block device as mass storage, but this linux needs a root (/) which is usually the partition we'd like to expose [17:48] suihkulokki: if you're changing blocks underneath it, you're using it wrong :) [17:48] Sharing the / would also be quite confusing on the PC side of things (usr dev home var lib etc.) [17:49] smagoun: that's hardly idiot^Wenduser-proof :P [17:49] (Ah smagoun already said what I just said, sorry) [17:49] bspencer, unless it requires lots of reworking of applications to not lose users data. [17:49] suihkulokki: that depends on how smart your apps are [17:50] So correct me if I'm wrong, it sounds like rebooting into a client-only mode will still require a separate partition for user data *if* we want to limit what we expose to the user? [17:50] should we move on to the samba mount over usb-network? [17:50] davidm, yes. losing data is not acceptable in any case. force-stopping their running video is ok. [17:50] smagoun: I think so; unless we have a special initrd or so [17:50] meeting time check, we on the intel oregon side have a hard stop of 10am for a training class [17:50] But it's quite a lot of engineering to have one IMO [17:50] Hmm not sure after all [17:51] rustyl_: Please [17:51] smagoun, we should look into that. Seems we could mount any directory as / if we reboot. anyway... [17:51] how do people feel about the usb network -> samba mount concept? [17:51] rustyl_: So is there any other way than RNDIS? Is RNDIS an issue in itself? [17:51] rustyl_: I like the fact that we could use the same technology over all bearers, but I'm not too happy that we expose "files" instead of pictures / movies etc. [17:52] rustyl_: I've had to do too much windows support to think that samba is a good idea for much of anything :) [17:52] i do not know if RNDIS is still an issue, but even before considering that... i fear all the moving parts to make the solution work [17:52] So Samba isn't my preferred option; UPnP would be something more tightly integrated for example [17:52] That said, from a technical (implementation) perspective it sounds safest - no partitioning to worry about, no translation, we can use ext3 on the device, etc [17:52] yeap, there are some really nice points [17:53] Doing IP might imply doing some DHCP -- or we could rely on default IP allocations on 169. (IIRC) [17:53] Can UPnP be used with non-media related files like documents, for instance? [17:53] i'm sure it could be made to work, but i fear it would be fragile [17:53] lool, correct. Just like WINCE and activeSync do. [17:54] bspencer, before you leave the meeting remember to do #endmeeting so Mootbot will correctly save logs. [17:54] are there any other paths we should consider? [17:54] davidm, check [17:54] rustyl_: over IP? or apart of IP? [17:54] anything [17:54] rustyl_: import/export from a USB flash drive (sneakernet), punt on USB client until we can do it right? [17:55] solutions to share data [17:55]