On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote: > On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > > + - Replace utmp, wtmp, btmp, and lastlog completely with journal > > We should definitely add the data needed to constuct this information, > if they are not already there. > > The tools could just use the journal directly, but there is the glibc api.
Exactly; barring a compatibility library that provides the same functions as glibc, which seems hazardous, I'd like to support tools that only know how to read and write those files directly. > > + - Provide one or more FUSE filesystems: > > + - Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials > > for all writes rather than limiting permissions > > That sounds like overkill. We should surely externalize the creation > of the files from systemd and make it optional to support legacy > stuff, otherwise these files should rather be phased out, than > emulated, I think. Separate, external, and optional, definitely; no sense running it if you have no tools around that read or write the format directly. But given that the glibc API (and corresponding expectations about the file format) will exist forever, it seems sensible to have a way to support that without actually having the files on the filesystem. > > + - Provide /var/spool/crash or equivalent, exposing an index of > > coredumps directly > > Coredump are really not consumed by any legacy thing that would need a > file system. What do you have in mind here. Specialized apps that need > that should just use the native API, not expect a file system, I > think. Just an idea for how to better satisfy user expectations. Approximately zero cost, mounted on demand, gives a view into the journal. > > + - Provide decoded text logs in /var/log > > I really don't think these plain text streams make much sense today. > If people want them, they should install syslog. Or some other project > can do that, I'm confident we do not want that code in systemd. Maintaining a separate copy of log messages seems like overkill; I want the data stored solely in the journal. And I agree that the code doesn't belong in the journal itself; I'm suggesting that a standalone FUSE filesystem based on the journal library would prove useful for compatibility with both tools that want to consume the log format and users used to /var/log. Seems pretty trivial to write, as well. > > + - Port upower to use the journal for historical power information used > > in future calculations > > Yeah, that would be useful. > > > + - Support optional database-style indexes for frequent or > > performance-critical queries > > Well, it is not a database, it's a pretty specialized format based on > bisection lists. What specific thing do you have in mind? Telling the journal in advance that you'd like to make a lot of queries for PROPERTY, or for PROPERTY=value, and having it maintain an index that makes such queries faster than a linear scan and filter. - Josh Triplett _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
