Re: [xml] running libxml in kernel space (fwd)



On Thu, Nov 13, 2003 at 02:38:21PM +0100, Gregor Zeitlinger wrote:
On Thu, 13 Nov 2003, Daniel Veillard wrote:
  Well if configured with --with-minimum to reduce the size and if
doing a minimal wrapping to use kmalloc and related memory functions
this might work. Linus would certainly call this foolish (apparently
he really dislike XML) but that sounds a fun thing to attempt in a 
dynamically loaded module.
it will be part of reiserfs. more specifically, reiserfs will be an xml
database.

  Okay then here is a few points I would like to raise:
    - If possible keep all XML processing in user space. XML processing
      CPU requirement cannot be bounded.
    - if you still need some kind of XML processing in-kernel then drop
      XML, use a subset, call it RFSML or whatever but not XML
    - drop any DTD or entity support from RFSML, except for the 5 predefined
      entities of XML
    - drop UTF-16 support requiremement of XML and stick to UTF-8 in RFSML
    - except for that stick as closely as possible to XML, especially
      w.r.t. the characters ranges checking, CR/LF processing,
      attribute value normalization, etc ...

  In my opinion XML-1.0 as defined should not be embedded in a kernel.
A subset will have to be defined. No correct XML-1.0 implementation
like libxml2 or expat is suitable for kernel inclusion. If a subset
still need to be used never label it as XML, but stick closely to 
XML where it makes sense, i.e. in the way the data analysis is done.
I think starting from libxml2 parser I could probably build a clean
and really fast "RFSML" parser, predicatble and small enough that
I would not feel totally insane putting it in a kernel. Still to me
the correct way is to not put XML or related markup parsing in the
kernel.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]