Cover photo
Greg Kroah-Hartman
Works at Linux


Greg Kroah-Hartman

Shared publicly  - 
First live demo of a working unipro switched phone with the greybus protocol just happened. A camera was added to the phone after it booted and it took a picture. Android becoming a dynamic system, it's about time :-)
Eduardo Valentin's profile photoJeshwanth Kumar N K's profile photoKrzysztof Wilczynski's profile photoDjalal Harouni's profile photo
+Nick Johnson I think I know the status of USB on Android :)

As for "what's so special" about this, this is a hardware protocol that prior to this implementation, was static, point to point, and not changeable.  Unipro has been around for about a decade in systems like phones, for the camera and displays and other things.  This phone turns Unipro into a routable and hotplugable system, fully dynamic.  It's way faster than USB and can be peer-to-peer if wanted (the main CPU doesn't get involved after the routes are set up), which is impossible on USB, and a major pain on PCI to get right (not to mention the security issues of PCI, which this system solves completely). It also allows you to tunnel a bunch of "legacy" hardware protocols across it like USB, serial, GPIO, I2C, I2S, SPI, and others, in ways that is almost transparent to the kernel drivers (totally transparent to USB and serial, 20-30 lines needed for other drivers), or export those protocols out to userspace applications so you can control your spi-based sensor module directly from an Android application, no special kernel support needed.

I can go on, and actually will in a few days at LinuxCon Japan with a talk all about this at that conference, so see the video of it if you are curious.

Oh, and all of the hardware, firmware, mechanical, and of course kernel code, is all open source, as well as the protocol specification, and you can look at it today and watch it evolve in our github repos.  No other project has ever done that before that I know of.

+Thomas Petazzoni yes, the work here is taking all of the things we did 10 years ago to make Linux the kernel dynamic, and make Android dynamic.  As you know, right now Android is very static, almost the whole system definition is determined at build time, and a few things at boot time, and almost nothing at run-time.  I don't think there's ever been a demo of Android adding a CSI camera to the system after it had booted.

The work here will eventually make Android fully dynamic, with devices being able to be added or removed on the fly.  You want 6 batteries, and then later remove 3 of them?  You want 2 wifi devices? Handle different cameras with different resolutions?  All will eventually not be an issue at all.  That will make it even easier to get an Android system up and running for the "old static" type machines as well, just like the work we did in Linux to make everything dynamic made all of the "static" laptops and servers trivial to setup properly.

In short, this is good shit.
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
I see more and more projects doing the "curl | sudo bash" method of installing something.  Not good on huge number of levels.  This is a good rant of people doing this for containers.

Yes, I know docker doesn't support signed images yet, hopefully that will happen someday...
None of these "fancy" tools still builds by a traditional make command. Every tool has to come up with their own, incomptaible, and non-portable "method of the day" of building. And since nobody is still able to compile things from scratch, everybody just downloads precompiled binaries from ...
Michael Faille's profile photoA. David's profile photoJorge Nerín's profile photoJonas Kalderstam (Space Cowboy)'s profile photo
+Edward Morbius Unless you trust the server your sourcing from....  But nothing connected to the public Internet can be trusted.
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
Retro computing combined with music, great work.
Sven Sternberger's profile photoDiego Ruggeri's profile photoChiang Keeper's profile photoDjalal Harouni's profile photo
Fantastic! Makes me miss my ZX81, wish I still had it.
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
The proper Parisian preparations for dealing with off-topic, non-technical kdbus email rants^Wcomplaints.
Yves-Alexis Perez's profile photoCristian Rodriguez's profile photoDjalal Harouni's profile photoCameron Wood's profile photo
+Carsten Niehaus yes it is.
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
Very nice, glad to see this happen.

I get people asking for a pid for the Linux Foundation VID, and unless your product has Linux inside it, I can't give it out.  This is a place for all of those "tiny" devices to get a valid pid.

On the other hand, people need to realize that 0x0000/0x0000 works just fine with all operating systems, as long as your device follows a USB class device specification.  That's the hack that a lot of Chinese devices have been using for years to get around the VID/PID mess.
Now, someone has finally done the sensible thing and put an unused USB VID to work. obtained the rights to a single VID – 0x1209 – and now they’re parceling off all the PIDs that remain to open source hardware projects.
6 comments on original post
Cyprien Laplace's profile photoIrshad Pananilath's profile photoSrikant Patnaik's profile photoNicolas Planel's profile photo
+Steven Harper a better alternative is to provide some way for companies to get device ids assigned to them without paying the huge fees the USB-IF requires.  When you want to make an open-hardware-based device, it's hard to justify the huge fee just for a single number.
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
I agree with +Olof Johansson.  And I'm a member of the UEFI group.  Yes, UEFI is fast, and quick in making new specs, but we need a way to post code, for hardware that ships before specs come out.  Heck, we need to publish code before the hardware is out.  Waiting for the spec release cycle to publish source just doesn't work these days.
I am shocked SHOCKED I SAY.

Luckily this would never, ever EVER happen on ARM. Because enterprise. Because standards.

The sticky part is that while there might be a standard, you can't force people to adhere to it. Once breakage is common enough people will assume the broken approach is the right one. The fact that UEFI/ACPI is developed in secret means that someone doing something ad-hoc is the only public example of how to do it, which further causes this to spread since there's no way to show them how to do it properly due to confidentiality requirements.

It'd be nice if UEFI could just scrap their silly NDAs. At times like these, it's obvious and clear that they are harmful for the whole industry.
[fw-summit] FW: [aswg] Some shipped machine exposed NvDIMM as type 12 at e820 table. Darren Cepulis Darren.Cepulis at Thu Apr 2 16:42:21 UTC 2015. Next message: [fw-summit] FW: [aswg] Some shipped machine exposed NvDIMM as type 12 at e820 table; Messages sorted by: [ date ] [ thread ] ...
8 comments on original post
Olof Johansson's profile photoB Cran's profile photoDaniel Stone's profile photoFranklin Berad's profile photo
Ok Greg
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
For those people who keep trying to use "uint32_t" and friends in the kernel, here's the old discussion about it, and why we don't use it.

Yes, the defines are in the kernel tree, due to foolish driver developers, but really, you all should know better...

Posted here because an email thread asked me about this, and I want to remember where it is in the future.

G+ as a bookmark manager, surely that's an abuse of its design...
On Mon, 29 Nov 2004, Paul Mackerras wrote: > > uint32_t is defined to be exactly 32 bits wide, so where's the problem > in using it instead of __u32 in the headers that describe the > user/kernel interface? (Ditto for uint{8,16,64}_t, of course. Ok, this discussion has gone on for too long ...
Marek Vašut's profile photoNathaniel Kim's profile photoWilliam Caldwell's profile photoBrian Oxley's profile photo
The email was specifically about exported header files, at a time when that concept did not exist yet. I hope nobody so far was crazy enough to use bool in those headers, which would be worse than using uint32_t. In driver code, it's not a bug to use uint32_t, __u32 or _Bool, though I'd always recommend using u32 and bool there for consistency. 
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
I got to see this recently, and it's amazing. Combine a great storyteller with amazing technology and good things happen.  It's now available for everyone to download. Watch it with headphones.
A day after leaving the "Fast and Furious" franchise, Justin Lin got a curious phone call. Lin, who had directed four of the street racing-themed action movies, was asked by Google to collaborate o...
Harald Mitterhofer's profile photoIrshad Pananilath's profile photoLucas Santos's profile photoJani Nikula's profile photo
Yeah, sorry...Spotlight eligible devices.  I can't imagine why a Nexus 7 can't display these media, but OK.  I guess it's for me to wonder and Google developers to know, because these Play doohickeys never tell you why your devices aren't compatible with the app.  Guess it's not going to happen for me.

In skimming through the page for the links, it didn't look like there was a direct link to this short movie.
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
eBPF is scary powerful, hopefully more people learn about it through example scripts like these.
I've taken one small step with eBPF, but it heralds one giant leap for Linux tracing. # ./bitehist Tracing block device I/O... Interval 5 secs. Ctrl-C to end. kbytes : count distribution 0 -> 1 : 3 | | 2 -> 3 : 0 | | 4 -> 7 : 3395 |************************************* | 8 -> 15 : 1 | | 16 -> 31 ...
Arun Bhanu's profile photoAsai Thambi S P's profile photoHenry Kleynhans's profile photoChristian Hudon's profile photo
extremely Bright Potential Future?  extra Badass Probe Functions?  entirely Beautiful Programmatic Flair?
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
#opticalexperiments Parisian style with +Valentin Rothberg and +Peter Senna Tschudin and real beer (i.e. Guinness or two...)
Jean-Michel Rubillon's profile photoIan Kumlien's profile photoSriram Ramkrishna (sri)'s profile photoPeter Senna Tschudin's profile photo
Beamish? come on now..
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
Mont Saint-Michel really is as cool as the pictures look.  A walled fortress/cathedral in the mouth of a river in the bay.  Never successfully attacked, and after visiting it, I understand why.

Visiting it at night is also nice, no crowds, great views, and spooky walks along the fortress walls.  I can't imagine how crowded it gets in the summer, but even then, I would recommend visiting it if you are nearby.
Byomkesh Das's profile photoNikita Danilov's profile photoPeter Boivin's profile photoIgor Gnatenko's profile photo
It looks stunning in summer, during low-tide. It is my profile picture for a few years. :-)
Add a comment...

Greg Kroah-Hartman

Shared publicly  - 
#opticalexperiment  French-style.

I was told later that by eating the items on the plate, I am not allowed to be imported into the USA.  With food like this, I don't think I want to go back home...
Mohamed-R. KAMARDINE's profile photoMadeline Kroah-Hartman's profile photoGrant Grundler's profile photoEugen Neuber's profile photo
Dessert! :) I stuck with sweeter stuff (Mousse Chocolat) and bought the cheese directly at the super market.
Add a comment...
  • Linux
Basic Information
Very nice place for dinner or lunch. Wonderful service, beautiful atmosphere, and very good food. Recommended if you are in the area.
Food: ExcellentDecor: ExcellentService: Excellent
Public - 2 years ago
reviewed 2 years ago
1 review