| 00:13.22 | *** join/#edev contempt (contempt@unaffiliated/contempt) |
| 00:17.53 | *** mode/#edev [+o landley] by ChanServ |
| 00:38.19 | *** mode/#edev [+o prpplague] by ChanServ |
| 00:59.59 | *** join/#edev wmat (wmat@wallace.mixdown.ca) |
| 01:00.42 | *** join/#edev Belliash (~belliash@asiotec/constitutive/belliash) |
| 01:02.28 | *** join/#edev djerome (~djerome@ip68-2-20-108.ph.ph.cox.net) |
| 01:05.15 | *** join/#edev wmat_ (wmat@wallace.mixdown.ca) |
| 01:09.46 | prpplague | CosmicPenguin: ping |
| 01:24.05 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 02:19.01 | *** join/#edev landley_ (~landley@c-50-148-218-118.hsd1.mn.comcast.net) |
| 02:35.25 | *** join/#edev mrcan__ (~mrcan@unaffiliated/mrcan) |
| 02:36.07 | *** join/#edev CosmicPe- (~nobody@znc.codeaurora.org) |
| 02:39.10 | *** join/#edev espiral (~maze@unaffiliated/espiral) |
| 02:40.45 | *** join/#edev landley_ (~landley@c-50-148-218-118.hsd1.mn.comcast.net) |
| 02:40.50 | *** join/#edev darknighte_znc_z (~darknight@nat-lmt.mentorg.com) |
| 02:43.56 | *** join/#edev darknighte (~darknight@pdpc/supporter/professional/darknighte) |
| 02:51.12 | *** join/#edev _Lucretia_ (~munkee@pdpc/supporter/active/lucretia) |
| 02:55.11 | *** join/#edev damkerngt (~Administr@27.130.45.99) |
| 03:09.27 | *** join/#edev mnemoc (~amery@2a01:4f8:100:2302:10::3) |
| 03:09.27 | *** join/#edev RushPL (~quassel@2a01:4f8:151:73a3::2) |
| 03:09.41 | *** join/#edev TheSeven (~quassel@rockbox/developer/TheSeven) |
| 03:51.20 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 05:39.25 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 05:46.49 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 06:08.19 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 06:29.37 | *** join/#edev slashbeast (~slashbeas@unaffiliated/slashbeast) |
| 07:00.25 | *** join/#edev bsdfox\ (~h36sa@107-221-62-129.lightspeed.frokca.sbcglobal.net) |
| 07:00.25 | *** join/#edev bsdfox\ (~h36sa@unaffiliated/bsdfox) |
| 07:36.01 | *** join/#edev florian (~fuchs@port-217-146-132-69.static.qsc.de) |
| 07:36.02 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 07:41.15 | *** join/#edev calculus (~calculus@adsl-76-254-63-61.dsl.pltn13.sbcglobal.net) |
| 07:41.15 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 07:54.01 | *** join/#edev bsdfox\ (~h36sa@107-221-62-129.lightspeed.frokca.sbcglobal.net) |
| 07:54.02 | *** join/#edev bsdfox\ (~h36sa@unaffiliated/bsdfox) |
| 07:59.26 | *** join/#edev bsdfox_ (~h36sa@107-221-62-129.lightspeed.frokca.sbcglobal.net) |
| 07:59.27 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 08:06.49 | Kasreyn | i'm wondering why this is printed: "watchdog: ioctl 0xc0045706 failed: Invalid argument". 0xc0045706 is ioctl WDIOC_SETTIMEOUT, yes? then it should be supported by the new framework.. (driver: http://code.google.com/p/linux-next-20130703-moxart/source/browse/drivers/watchdog/moxart_wdt.c) (log: http://ideone.com/YZrawb) (busybox version: 1.22.0) |
| 08:16.53 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 09:10.25 | *** join/#edev keesj (~keesj@pc-020965.clients.vu.nl) |
| 09:14.30 | *** join/#edev bsdfox (~h36sa@107-221-62-129.lightspeed.frokca.sbcglobal.net) |
| 09:14.30 | *** join/#edev bsdfox (~h36sa@unaffiliated/bsdfox) |
| 10:19.49 | *** join/#edev icanicant (~klawson@195.88.236.129) |
| 11:07.29 | *** join/#edev bsdfox\ (~h36sa@unaffiliated/bsdfox) |
| 11:14.05 | *** join/#edev g1powermac (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 11:14.05 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 11:19.09 | *** join/#edev jackmitchell (~Thunderbi@host217-34-104-101.in-addr.btopenworld.com) |
| 11:43.52 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 13:16.38 | *** join/#edev g1powermac (~g1powerma@rrcs-173-197-150-13.west.biz.rr.com) |
| 13:16.39 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 13:29.11 | *** join/#edev orbarron (~a0271968@nat/ti/x-kklphzwxswioazjb) |
| 13:58.21 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 14:15.24 | *** join/#edev dgerlach (~a0274052@192.94.92.11) |
| 14:39.15 | *** join/#edev espiral (~maze@unaffiliated/espiral) |
| 14:53.46 | *** part/#edev dgerlach (~a0274052@192.94.92.11) |
| 15:06.28 | *** part/#edev orbarron (~a0271968@nat/ti/x-kklphzwxswioazjb) |
| 15:07.09 | *** join/#edev prpplague (~danders@adsl-68-88-78-230.dsl.rcsntx.swbell.net) |
| 16:46.22 | *** join/#edev Umeaboy (~Umeaboy@213-21-78-12.customer.t3.se) |
| 17:01.30 | *** join/#edev dijenerate (~dijenerat@65.48.221.118) |
| 17:05.29 | *** join/#edev ffio (~fire@unaffiliated/security) |
| 17:21.55 | *** join/#edev groglogic (~groglogic@68-25-9-70.pools.static.spcsdns.net) |
| 17:24.28 | *** join/#edev blueness (~blueness@gentoo/developer/blueness) |
| 17:29.26 | *** join/#edev prpplague (~danders@adsl-68-88-79-206.dsl.rcsntx.swbell.net) |
| 17:32.28 | *** join/#edev groglogic (~groglogic@68-25-9-70.pools.static.spcsdns.net) |
| 17:33.31 | *** join/#edev groglogic (~groglogic@68.25.9.70) |
| 17:44.00 | *** join/#edev NightMonkey (~NightrMon@64.124.185.45) |
| 17:44.00 | *** join/#edev NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 17:55.02 | *** join/#edev florian (~fuchs@sign-4db6ae5c.pool.mediaWays.net) |
| 17:55.02 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 18:08.43 | *** join/#edev g1powermac (~g1powerma@rrcs-74-87-150-6.west.biz.rr.com) |
| 18:08.44 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 18:08.49 | *** join/#edev blueness (~blueness@gentoo/developer/blueness) |
| 18:17.15 | slashbeast | Does bootloader load initramfs in memory and tells kernel where it is or kernel loads it? |
| 18:17.26 | slashbeast | how the boot process looks on low-level? |
| 18:35.22 | *** join/#edev landley_ (~landley@c-50-148-218-118.hsd1.mn.comcast.net) |
| 18:36.42 | SpeedEvil | It depends on the configuration. |
| 18:38.09 | *** join/#edev groglogic (~groglogic@ip-64-134-29-197.public.wayport.net) |
| 18:38.30 | SpeedEvil | Generally, the initramfs is built into the kernel |
| 18:39.27 | SpeedEvil | Or, it can be passed the address by the bootloader. |
| 19:03.22 | *** join/#edev NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 19:20.45 | *** join/#edev bsdfox_ (~h36sa@107-221-62-129.lightspeed.frokca.sbcglobal.net) |
| 19:20.46 | *** join/#edev bsdfox_ (~h36sa@unaffiliated/bsdfox) |
| 19:30.22 | landley | slashbeast: I wrote documentation on this... |
| 19:30.56 | landley | https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt |
| 19:31.08 | landley | Let me know if it needs to be updated... |
| 19:31.59 | *** join/#edev c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) |
| 19:35.31 | SpeedEvil | :) |
| 19:37.03 | *** join/#edev blueness (~blueness@gentoo/developer/blueness) |
| 19:45.36 | *** join/#edev Zygo (foobar@startkeylogger.hungrycats.org) |
| 19:46.04 | *** join/#edev SpeedEvil_ (~quassel@tor/regular/SpeedEvil) |
| 19:47.54 | *** join/#edev ccole_ (~cole@coledd.com) |
| 19:48.28 | *** join/#edev uwe_mobile__ (~uwe@static.88-198-8-117.clients.your-server.de) |
| 19:49.03 | *** join/#edev jonmasters_ (~jcm@edison.jonmasters.org) |
| 19:52.51 | *** join/#edev av500 (~vladimir@b2b-46-252-131-98.unitymedia.biz) |
| 19:59.20 | *** join/#edev prpplague (~danders@adsl-68-88-79-206.dsl.rcsntx.swbell.net) |
| 20:00.35 | *** join/#edev dijenerate (~dijenerat@65.48.221.118) |
| 20:02.19 | *** join/#edev XandriX (xandrix@gateway/shell/anapnea.net/x-nvxcryidgfqfdrhw) |
| 20:32.07 | slashbeast | landley: the only thing I think could be fixd is some double spaces |
| 20:39.57 | *** join/#edev dijenerate (~dijenerat@65.48.221.118) |
| 20:41.44 | slashbeast | landley: it does not cover the part where initramfs is mapped into memory by bootloader and passed the addressspace to kernel. |
| 20:41.54 | slashbeast | landley: I know its pretty x86 thing, but worth nothing |
| 20:44.51 | *** join/#edev ntfreak_ (~ntfreak@unaffiliated/ntfreak) |
| 20:54.57 | slashbeast | landley: anyway, its awesome, a good info about ramfs, initrd vs initramfs. |
| 20:55.15 | slashbeast | gonna bash with it people at work tomorrow morning |
| 20:55.21 | slashbeast | no mercy! |
| 21:01.01 | landley | slashbeast: early boot memory layout varies per target. |
| 21:01.17 | landley | I've since delved into bootloader stuff. Haven't written one yet, dowanna. |
| 21:01.51 | slashbeast | I was arguing with my coworksers about what initramfs is etc but had no solid argumetns than 'I was there, I tested that, trust me' |
| 21:02.25 | landley | The one thing I'm aware of that's technically wrong in that document is "initramfs will be tmpfs based if you enable tempfs". |
| 21:02.33 | landley | I pushed a patch to make that true ~3 weeks ago. |
| 21:03.05 | landley | And Linus said I should send it through Andrew Morton's tree: http://lkml.indiana.edu/hypermail/linux/kernel/1307.1/00868.html |
| 21:04.07 | slashbeast | linux is a moron |
| 21:04.17 | slashbeast | he prooved it multiple times, regarding security aspects |
| 21:04.21 | slashbeast | silent patches and shit |
| 21:04.37 | slashbeast | same goes for GrehKH |
| 21:04.51 | slashbeast | GregKG^ |
| 21:05.20 | landley | He's smarter than me. He's not infallible. |
| 21:05.26 | slashbeast | please. |
| 21:05.36 | landley | You're welcome to maintain your own kernel. |
| 21:05.37 | slashbeast | he's marketing type of guy |
| 21:05.42 | landley | torvalds? |
| 21:05.45 | slashbeast | ya |
| 21:05.51 | slashbeast | you do things, he talk things |
| 21:05.51 | landley | That's an epically clueless statement, dude. |
| 21:05.59 | landley | he's done more in a year than I have in my career. |
| 21:06.03 | slashbeast | from my freely point of view |
| 21:06.06 | landley | I follow what he does. |
| 21:06.08 | landley | I do userspace stuff. |
| 21:06.14 | landley | The stuff he does, you don't even _see_. |
| 21:06.24 | landley | Because from your perspective, it just works. |
| 21:06.26 | slashbeast | whatsoever, his false sense of security is unquestionable |
| 21:06.53 | slashbeast | and recent udev/systemd madness he allows to happen |
| 21:07.17 | slashbeast | Greg supports this insane attempts. |
| 21:07.24 | slashbeast | and Torvalds is all after Greg |
| 21:07.58 | slashbeast | didnt recently Greg told people that he dont give a shit about thier patches? |
| 21:08.23 | slashbeast | "I Don't Want Your Code" |
| 21:08.24 | landley | http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01706.html |
| 21:08.36 | landley | http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01889.html |
| 21:08.55 | slashbeast | I know that story, landley. |
| 21:08.57 | landley | slashbeast: I saw that video, yes. You're missing rather a lot of context. |
| 21:09.05 | landley | "A maintainer's job is to say no" - Alan Cox. |
| 21:09.37 | slashbeast | the 2nd link, I dont remeber it. |
| 21:09.46 | landley | I did a talk on that (the prototype an dthe fan club one, it was a sleep-deprived um-fest and the the first couple minutes are missing from the recording.) |
| 21:10.03 | slashbeast | there is a video record? |
| 21:10.25 | landley | I refer to Greg KH as "my nemesis". |
| 21:10.37 | landley | However, I know (and respect) what he does for the kernel. |
| 21:10.45 | landley | I disagree with what he does in userspace. |
| 21:10.56 | landley | But then Linus isn't good at userspace either (git's user interface is horrible). |
| 21:11.05 | landley | I'm not that great at kernel space, I can do it, but I do it badly. |
| 21:11.27 | slashbeast | well, I also respec what greg and linus did, in general. |
| 21:11.36 | landley | Realtime programming on an 8k stack where everything is an asynchronous callback avoiding spinlocks via RCU. |
| 21:11.38 | slashbeast | because where we stands here is thanks to them, mostly. |
| 21:12.18 | slashbeast | but your work alone, landley, is in my opion as important as linux as whole. |
| 21:12.33 | SpeedEvil | ... |
| 21:12.40 | landley | google "greg kh don't want your code", first hit's the video... |
| 21:13.02 | landley | slashbeast: no, you're just closer to it. |
| 21:13.15 | landley | Nearer things look larger. |
| 21:13.32 | slashbeast | would you care to elaborate? |
| 21:13.48 | landley | I documented initramfs. I didn't write or design initramfs. |
| 21:14.10 | landley | Linus is _right_ to dismiss the inittmpfs patches as minor because I didn't write tmpfs (alan cox did). (Al Viro wrote initramfs. Linus wrote ramfs.) |
| 21:14.30 | groglogic | landley: RCU is Read-Copy-Update? (sorry, caught the tail end of your convo about Linux devs) |
| 21:14.33 | landley | The whole "mount the page cache as a filesystem" thing was the result of something like 8 years of infrastructure rework to make it more generic, which I followed on the list. |
| 21:14.45 | landley | groglogic: yeah, that's Paul McKenney's thing. |
| 21:14.57 | groglogic | landley: k thx |
| 21:14.59 | landley | He's at IBM now (they licensed the patents to linux), he came from... oh, the company that invented numa. |
| 21:15.04 | landley | Interociter. |
| 21:15.07 | landley | Intersil. |
| 21:15.08 | landley | Interdata. |
| 21:15.10 | landley | Something like that. |
| 21:15.26 | slashbeast | are you happy with the current userspace maddness you have there? Udev, systemd, policykit, consolekit, pulseaudio |
| 21:15.29 | slashbeast | this is madness |
| 21:15.33 | slashbeast | guass who think its good idea |
| 21:15.39 | slashbeast | greg, |
| 21:16.24 | landley | slashbeast: I wrote mdev as a reaction to udev eight years ago. |
| 21:16.30 | SpeedEvil | A clean-sheet design would be nice - yes. |
| 21:16.37 | slashbeast | and I use mdev day to day. |
| 21:16.47 | SpeedEvil | Either find one you like, and popularise it, or write one, and popularise it. |
| 21:16.56 | landley | and all that stuff you mention is lennart pottering, not greg. |
| 21:16.58 | slashbeast | on every single linux system I own. |
| 21:16.59 | SpeedEvil | And yes - inertia is a major, major problem. |
| 21:17.05 | landley | And udev only got _really_ bad when Kay Sievers jumped on board. |
| 21:17.20 | slashbeast | lennart, greg, kay, 'one thing' |
| 21:17.26 | landley | These days devtmpfs does 2/3 of what mdev was designed to do. |
| 21:17.58 | slashbeast | you can't config devtmpfs to apply specified perms to specified devices |
| 21:18.08 | slashbeast | which renders it useless, or not more useful than static dev on tmpfs. |
| 21:19.15 | landley | Sequent, that was it. |
| 21:19.25 | landley | The name o the company Paul McKenney worked for before IBM bought it. |
| 21:19.45 | landley | slashbeast: unfortunately, you _can_. |
| 21:19.51 | slashbeast | also, mdev is kind of lacking behind mdev in busybox. |
| 21:19.53 | landley | Which discussion is a can of worms and I'm at work right now... |
| 21:20.01 | landley | slashbeast: toybox's mdev is a stub. |
| 21:20.25 | landley | I'm unaware of another mdev besides the busybox and toybox ones. I wrote it, from scratch, for busybox. |
| 21:20.32 | landley | solar@gentoo helped with the config file design. |
| 21:20.57 | slashbeast | last time I checked the toybox's one, it lacked the features to serialize requiest, and now denys added ENV= support thats pretty awesome |
| 21:23.14 | landley | The toybox one is missing all sorts of stuff. It's about 1/3 of what's needed. |
| 21:26.13 | slashbeast | but the non-gpl licence is totaly worth it |
| 21:33.10 | landley | Working on it. :) |
| 21:40.18 | MonMotha | I'm still waiting for kitchensinkd |
| 21:48.34 | *** join/#edev prpplague (~danders@adsl-68-88-79-206.dsl.rcsntx.swbell.net) |
| 21:53.16 | roxfan | MonMotha: don't give them ideas! |
| 21:55.06 | MonMotha | heh |
| 21:55.11 | landley | MonMotha: it's called "systemd". |
| 21:55.18 | MonMotha | landley: that's kinda what I was poking fun of |
| 21:56.51 | MonMotha | so suppose I have an I2C driver (this is for a barebones/minimal RTOS system, not Linux) that supports linked-list chaining of transfer descriptors so as to make e.g. back-to-back write/read for EEPROMs easy |
| 21:57.28 | MonMotha | does it seem reasonable to make the submission function just tack your request onto the end of the existing queue, or does it seem more sensible to actually lock the controller and make the caller wait? |
| 21:57.43 | MonMotha | obviously that's crazy contextual in terms of what's "best". I'm just looking for "what seems less surprising and/or more useful |
| 21:58.48 | roxfan | adding to the list should work unless you need it done right away |
| 21:59.24 | roxfan | but you need to make sure that the controller won't be reading the end of the queue as you're modifying it |
| 21:59.56 | MonMotha | roxfan: the queue is managed in software, so a critical section takes care of that |
| 22:00.06 | roxfan | ah okay |
| 22:00.42 | MonMotha | and neither approach really lets you get things done "right away". I could have a notion of an "urgent" request, but then you worry about splitting up transactional groups of requests, so you have to add the concept of barriers, etc., and that's a mess. |
| 22:01.07 | roxfan | some dma controllers can do scatter/gather, so it could be hw-assisted too |
| 22:01.58 | MonMotha | well, my DMA controller can, and I do have a global concept of a scatterlist |
| 22:02.11 | MonMotha | but I haven't written the code to make my DMA controller handle them, yet |
| 22:02.51 | MonMotha | the I2C controller is such that software intervention is required to start and finish a transfer (especially reads), anyway, so I can't just go all ronco showtime rotisserie on it |
| 22:03.32 | MonMotha | well, that may not be strictly true - I may be able to use the scatter-gather and channel triggering features to essentially do all that with the DMA controller |
| 22:03.47 | MonMotha | but I think setting all that up may have more software overhead than just handling a couple extra IRQs :) |
| 22:14.55 | *** join/#edev NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 22:36.25 | *** join/#edev prpplague (~danders@adsl-68-88-79-206.dsl.rcsntx.swbell.net) |
| 22:38.49 | *** join/#edev jonmasters (~jcm@edison.jonmasters.org) |
| 23:21.38 | *** join/#edev groglogic (~groglogic@ip-64-134-29-197.public.wayport.net) |
| 23:28.55 | *** join/#edev groglogic (~groglogic@ip-64-134-29-197.public.wayport.net) |