From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from tb-mx1.topicbox.com (localhost.local [127.0.0.1]) by tb-mx1.topicbox.com (Postfix) with ESMTP id 756EE1D98283 for ; Wed, 17 Jul 2024 16:47:25 -0400 (EDT) (envelope-from echosoft.llc@gmail.com) Received: from tb-mx1.topicbox.com (localhost [127.0.0.1]) by tb-mx1.topicbox.com (Authentication Milter) with ESMTP id 9CAA48BECA2; Wed, 17 Jul 2024 16:47:25 -0400 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1721249245; b=sq7g3XXISyZAmfj+hWT+1drv3GxyXwZEWbV32HuQIM/MpYOfWm ZyalA1LMFeSQrzo8rZOEAxwggArd13gg8129D8zhYyXvYI4dMPvlg3PAS85ZDKFl BYcrqAHmXoWj1TJi5zHwsSWq9Uu3puqOQXSxvxKTngd2ZhuVyDIbsn0GfYnh6x+R Mcgu+LWbmFP5zuaoHUZxFqLtXEIOQkdGuLTDErFu9w+fqcfdotsBiNY7YGA9Qfpl IKCrOJy+exMw0vnAC+4/Mpv/y9TWwmPiqA2fS7Xr/AVUIkou/gHaLfJUcZGO7v2Q NOHex5IUHQAS5k7HpaZRz/SKmx+vKp7O0LPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=from:content-type:content-transfer-encoding :mime-version:date:subject:message-id:references:in-reply-to:to; s=arcseal; t=1721249245; bh=u98+7pdQt+e8PaKErpavPzW+DrrAWvFXWLI H+tcP9Sg=; b=sR70Y8TG3n9oEwUh0rcSuM9naO+RJwPts/7QRd+DypXay4uWbiW em8HDVIdWqaMoiNuEpmjLvjz1fZ65Q4JvQ5UW1sZeKDhE0y15gkiEu5VysLzvJGH ewTEgvFS+I+g5QM0gOS0v9pUjMrEvA5LOCw7nxvapLBHXIU4FYFywufmTkpmWAHN ziPWguLUM/YzJFOGX0tLiXZC9/Z/yqmGl4ZARdhOdHbTCb4z4aDNqtBU0uqBSWLf iNz3/w4vImM4Agylt12fa7b1UfmR3MfL8qRDyTpVl27UhBcJFs/A3uVcALyWe1uN fdzPwhdCLDeyNaSDHzkgRUNklWMGmw3vKdA== ARC-Authentication-Results: i=1; tb-mx1.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=PKsh/1xG header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.166.52 (mail-io1-f52.google.com); spf=pass smtp.mailfrom=echosoft.llc@gmail.com smtp.helo=mail-io1-f52.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=OG2LZCqI; x-me-sender=none; x-ptr=pass smtp.helo=mail-io1-f52.google.com policy.ptr=mail-io1-f52.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=-100 state=0 Authentication-Results: tb-mx1.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=PKsh/1xG header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.166.52 (mail-io1-f52.google.com); spf=pass smtp.mailfrom=echosoft.llc@gmail.com smtp.helo=mail-io1-f52.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=OG2LZCqI; x-me-sender=none; x-ptr=pass smtp.helo=mail-io1-f52.google.com policy.ptr=mail-io1-f52.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=-100 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgeeftddrgeejgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnth hsucdlqddutddtmdenucfjughrpefhtgfgggffuffkfhgjvffosegrjehmrehhtdejnecu hfhrohhmpeflohhhnhcujfhofigrrhguuceovggthhhoshhofhhtrdhllhgtsehgmhgrih hlrdgtohhmqeenucggtffrrghtthgvrhhnpeekleevfeejfffgfeevuefhvddvfeeftefg leeuudekudduteeuhefgjeeuueefffenucffohhmrghinhepghhithhhuhgsrdgtohhmpd htohhpihgtsghogidrtghomhenucfkphepvddtledrkeehrdduieeirdehvddpvdeitdej mehfsgeltdemsghfvdegmegutdduleemvggtsggumeegfedvvdemudekheegmeekrggtsg enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpedvtdelrdekhedr udeiiedrhedvpdhhvghlohepmhgrihhlqdhiohduqdhfhedvrdhgohhoghhlvgdrtghomh dpmhgrihhlfhhrohhmpeeovggthhhoshhofhhtrdhllhgtsehgmhgrihhlrdgtohhmqedp nhgspghrtghpthhtohepuddprhgtphhtthhopeeouggvvhgvlhhophgvrheslhhishhtsh drihhllhhumhhoshdrohhrgheq X-ME-VSScore: -100 X-ME-VSCategory: clean Received-SPF: pass (gmail.com ... _spf.google.com: Sender is authorized to use 'echosoft.llc@gmail.com' in 'mfrom' identity (mechanism 'include:_netblocks.google.com' matched)) receiver=tb-mx1.topicbox.com; identity=mailfrom; envelope-from="echosoft.llc@gmail.com"; helo=mail-io1-f52.google.com; client-ip=209.85.166.52 Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tb-mx1.topicbox.com (Postfix) with ESMTPS for ; Wed, 17 Jul 2024 16:47:24 -0400 (EDT) (envelope-from echosoft.llc@gmail.com) Received: by mail-io1-f52.google.com with SMTP id ca18e2360f4ac-80a2939265cso800039f.3 for ; Wed, 17 Jul 2024 13:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721249243; x=1721854043; darn=lists.illumos.org; h=to:in-reply-to:references:message-id:subject:date:mime-version :content-transfer-encoding:from:from:to:cc:subject:date:message-id :reply-to; bh=u98+7pdQt+e8PaKErpavPzW+DrrAWvFXWLIH+tcP9Sg=; b=PKsh/1xGGfltKNyOitCnTSCEp7siSvL34QTaXLgOfA3rWZKo8r7BpJVs6ajhlO63Az 4l8hPmyogYvUWF+QXU8nUEfjxtcdbbGC/LIrePrvmW83S2cOSZrjhcHxW6QPNeW0oC/C UhF/zOXHNnuBfor8jnMahsT8jgOCEKQUhDxrw7GLUhPR/W8mlvuuZwIk3qYXDMDY65SI W4WR8GMmzXzzFdCYeJs1gUwM/9CwhhyuBUatZtkUwOHkNs6TotD/WjJDAMKiIyyaf3Da 0r071zb3hMXWKw4rTaivJQVjbHdhfKOhqW19zyF+fgjBr3C4wCVmSyidKIaFkyRaA9QG w6dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721249243; x=1721854043; h=to:in-reply-to:references:message-id:subject:date:mime-version :content-transfer-encoding:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u98+7pdQt+e8PaKErpavPzW+DrrAWvFXWLIH+tcP9Sg=; b=OG2LZCqIC61LM8s4iAs4wkYEW1ifB12oReGHCYkql/zQdtSNVWNenkuqYpyTdx6ol6 agrCJiG3iMGXMMf2Mt5oaiS2hOD5LJeR9tYoPghzL0TlZAod7EjwsdgJXzL0ltp1RVVa ogRvFBUtcnJU/21tmEwxDki02rWN5viBBnbUBh56iQsUXa7j0WBk4jG0/RZkIUzQlXnN UAnEK9/i1LN2K1VmcIUiQ/mlt0I9pnYsCTqSPXeID1uIVS9cN3Pu70en0o0R9zd5jVCt rfYdVsx++82qAdTZg4YfP7muapHx96+WRk2m2kZyEYTuqNLtGGtdPUBnFV4HSSkq8UC1 XGLg== X-Gm-Message-State: AOJu0YzCgkiPuqXh9/XNy2VtdGV2P/F9SHqLfy7PeWfpEm0r9jqyPQYA eaIn7CoGBMow1S3I+KphZlxbJZlm577T9qa5diGLZsfiQ/DxbTMDVsGgaQ== X-Google-Smtp-Source: AGHT+IHa+2rTbkvr3+c2JfKVAroXCkYYzOG8gkmUxAOFMiE4p1cDpVwvjj3qiWDS8p+ibQsHCvLLQQ== X-Received: by 2002:a05:6602:158f:b0:803:cc64:e0d6 with SMTP id ca18e2360f4ac-817100401f1mr381056339f.1.1721249243097; Wed, 17 Jul 2024 13:47:23 -0700 (PDT) Received: from ?IPv6:2607:fb90:bf24:d019:ecbd:4322:1854:8acb? ([2607:fb90:bf24:d019:ecbd:4322:1854:8acb]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4c210f23f1csm932448173.102.2024.07.17.13.47.22 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2024 13:47:22 -0700 (PDT) From: John Howard X-Google-Original-From: John Howard Content-Type: multipart/alternative; boundary=Apple-Mail-6C83CEA4-6171-44EB-BBD1-914962831500 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 17 Jul 2024 15:47:21 -0500 Subject: Re: [developer] A couple of kernel questions Message-Id: References: <48-6697c700-1d7-71122080@11933559> <936d4a1e-9fb3-4ee8-8ee6-870c33cd20de@outstep.com> In-Reply-To: <936d4a1e-9fb3-4ee8-8ee6-870c33cd20de@outstep.com> To: illumos-developer X-Mailer: iPhone Mail (16G102) Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: c92e6e3c-447d-11ef-8aac-ba2e41b31357 --Apple-Mail-6C83CEA4-6171-44EB-BBD1-914962831500 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Nano-X (formerly MicroWindows) is a minimal replacement for both X11 and Win= 32 API. A Nano-X UI and Nuklear UI are also supported. Anti-grain rendering.= Some have integrated it to render to OpenGL, or Frame Buffer. Nano-X is on github. Thank you to the devs for your patience on this subject. -- John On Jul 17, 2024, at 3:22 PM, Lonnie Cumberland via illumos-developer wrote: Hi Joshua, I sincerely Thank you for the in-dept discussion on these questions/ideas an= d will investigate them further. Also, I am starting the stage of working on the prototype and am setting up b= ut build environment for this purpose. Will probably use X11/Xorg to get sta= rted along with VNC from the Bhyve side but definitely will be seeing what i= t might take to port DirectFB2 over as well. Lastly, I think that you are right and I will move to have more discussions o= n these things over at the "illumos-discuss" list and do apologize to everyo= ne for the off-topic and tangential discussion not specifically related to k= ernel development. Hope to see you over on the illumos-discuss list. Best and have a great evening Lonnie > On 7/17/2024 4:09 PM, Joshua M. Clulow via illumos-developer wrote: > On Wed, 17 Jul 2024 at 06:29, Lonnie via illumos-developer > wrote: >> 1. As Illumos is designed for zones (VMs), I am wondering if there are dr= iver and service zones implemented such that if a driver crashes then it doe= s not heavily impact the OS in operation? =46rom what I understand so far,= the drivers and system wide services are installed in the Global-Zone which= makes me think of the Xen Type-1 Hypervisor in which these things are insta= lled in their Dom0 which is similar to the Illumos Global-Zone (GZ) > It's not so much that illumos is designed _for_ zones or VMs, as that > we have first class features in the OS that support those things. > Aside from those features, illumos is a UNIX operating system with a > monolithic kernel. Drivers are generally kernel modules, though there > are limited areas in which drivers can be implemented in user mode > software; e.g., ugen(4D) allows for user mode USB drivers, and one of > the FUSE ports would allow for a user mode file system. That said, > because our consolidation can ship both kernel and user mode software, > we can indeed relatively easily move some things into daemons where > they might have ended up in the kernel in other systems. >=20 > We ship a lot of daemons for different purposes, supervised by smf(7) > and in may cases deprivileged by rbac(7) and privileges(7) features in > the OS. In most or all cases, these daemons could crash and restart > without necessarily bringing down other parts of the system. If a > daemon restart does cause unavailability, you could definitely file > that as a bug to fix. >=20 >> 2. Another crazy thought that I had was about the possibly of investigati= ng what it might take to (fork illumos for an experiment) and try to remove t= he dependencies on a hierarchal tree-based filesystem and to implement a typ= e of "Property-Graph Database (PGDb)" filesystem. The rationale here is tha= t a hierarchal tree-based filesystem can easily be represented as well but t= hat a PGDb filesystem also allows for assigning new types of attributes to f= iles, blocks, objects, users, etc. and thus allowing for granular security o= n users at the application level. Users can be allowed/disallowed to see/ac= cess application/files/block/objects and only authorized applications are "m= apped" to a particular user. > I think it's unlikely that we would move away from a hierarchical file > system. It's really at the core of a lot of UNIX abstractions. We > tend to focus on mandatory access control through privileges(7) and > rbac(7) mechanisms. Individual users, or processes, can be restricted > from seeing quite a lot of other things occuring on the computer in > other accounts, etc, by removing privileges from their processes. > They can be prevented from making network connections, or seeing other > processes in /proc, etc. We're always interested in new security and > sandboxing features, but would generally like them to build on and fit > in with the existing designs where possible. The core team is happy > to help with design advice if someone wants to put together an illumos > project discussion (IPD) document that covers a new sandboxing > feature; see: https://github.com/illumos/ipd. >=20 > ZFS, our primary file system, has extensive support for extended > attributes. It also has rich support for NFSv4 ACLs, which allow for > fine-grained permissions in the regular file system; see acl(7) for > more details. There is also support for other more complex > attributes, such as marking things totally immutable; see fgetattr(3C) > and chmod(1) for more details. >=20 >> 3. I could see that when a user does a login, then a blank empty zones is= set up at which time their configured files, directories are mapped in to t= heir container zone and allowed applications are only used. The users cannot= escape their zone and does not have access to the rest of the system unless= privilege's are elevated. I know that "zlogin" can do this from the GZ, bu= t perhaps automatically and full console since graphic display will be neede= d. > You could achieve a lot of automatic provisioning for users on login > through some combination of NSS and PAM modules and > distribution-specific control software. I don't think this would > really be a core illumos feature, at least to begin with, but there's > a lot of mechanism that could help you get there! >=20 > Graphics is obviously something of an uncharted challenge. As I > mentioned in your OmniOS thread, our DRM/KMS software needs work to be > brought up to date, and there are probably new facilities that we > would then need to add to the core OS to provide a richer graphical > console experience. It's also possible that you could, once DRM is > sorted out, drive a lot of that from distribution-specific software > like X11, or a port of DirectFB2, etc, without needing much or any > additional core OS support. >=20 >> 4. One need that may be a challenge to get done will be the need for a en= able/disable consoles such that a local users could use a hot-key (API call)= to switch between zone consoles which would include graphics, audio, etc. = This would be akin to running multiple VirtualBox OSs, or VMware Guests in w= hich you can step through the guest graphic tabs in fullscreen mode, perhaps= . I am seeking to replicate that idea in Illumos to step through guests (may= be in Bhyve or native zones) that are in their own configured zone which is t= he thought. > This is mostly the same as my comments on graphics above. Some work > will be required specifically on improving the graphical/desktop > support we have, as part of a project like that. >=20 >> I am not sure how these things might be approached and/or tackled in illu= mos but wanted to start investigating them one by one and build up at the pr= oject evolves. > I suspect most of what you want to do, you could get started by > prototyping on top of facilities that exist already! I can't stress > enough that if you want the graphics stuff to work out, I would work > on that first, as I think it's the biggest risk/unknown in your plans > so far. >=20 >> Well, I thought that I would ask these questions here since they are more= kernel related than OS configuration related and hope that you also find th= em interesting although may have already been considered in the past well. > We generally try to keep the illumos developer list focused on > specific bits of in-progress development (questions about how to > proceed, code and design reviews), or about specific bugs or issues, > etc. Generally we would do broad, exploratory ideation on the > illumos-discuss list. >=20 > Cheers. illumos / illumos-developer / see discussions + participants + delivery opti= ons Permalink= --Apple-Mail-6C83CEA4-6171-44EB-BBD1-914962831500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Nano-X (formerly MicroWindows) is a minimal replacement for both X11 and Win32 API. A Nano-X UI and Nuklear UI are also supported. Anti-grain rendering. Some
have integrated it to render to OpenGL, or Frame Buffer.

Nano-X is on github.

Thank you to the devs for your patience on this subject.

-- John

On Jul 17, 2024, at 3:22 PM, Lonnie Cumberland via illumos-developer <developer@lists.illumos.org> wrote:

Hi Joshua,

I sincerely Thank you for the in-dept discussion on these questions/ideas and will investigate them further.

Also, I am starting the stage of working on the prototype and am setting up but build environment for this purpose. Will probably use X11/Xorg to get started along with VNC from the Bhyve side but definitely will be seeing what it might take to port DirectFB2 over as well.

Lastly, I think that you are right and I will move to have more discussions on these things over at the "illumos-discuss" list and do apologize to everyone for the off-topic and tangential discussion not specifically related to kernel development.

Hope to see you over on the illumos-discuss list.

Best and have a great evening
Lonnie

On 7/17/2024 4:09 PM, Joshua M. Clulow via illumos-developer wrote:
On Wed, 17 Jul 2024 at 06:29, Lonnie via illumos-developer
<developer@lists.illumos.org> wrote:

1. As Illumos is designed for zones (VMs), I am wondering if there are driver and service zones implemented such that if a driver crashes then it does not heavily impact the OS in operation?   From what I understand so far, the drivers and system wide services are installed in the Global-Zone which makes me think of the Xen Type-1 Hypervisor in which these things are installed in their Dom0 which is similar to the Illumos Global-Zone (GZ)

It's not so much that illumos is designed _for_ zones or VMs, as that
we have first class features in the OS that support those things.
Aside from those features, illumos is a UNIX operating system with a
monolithic kernel.  Drivers are generally kernel modules, though there
are limited areas in which drivers can be implemented in user mode
software; e.g., ugen(4D) allows for user mode USB drivers, and one of
the FUSE ports would allow for a user mode file system.  That said,
because our consolidation can ship both kernel and user mode software,
we can indeed relatively easily move some things into daemons where
they might have ended up in the kernel in other systems.

We ship a lot of daemons for different purposes, supervised by smf(7)
and in may cases deprivileged by rbac(7) and privileges(7) features in
the OS.  In most or all cases, these daemons could crash and restart
without necessarily bringing down other parts of the system.  If a
daemon restart does cause unavailability, you could definitely file
that as a bug to fix.


2. Another crazy thought that I had was about the possibly of investigating what it might take to (fork illumos for an experiment) and try to remove the dependencies on a hierarchal tree-based filesystem and to implement a type of "Property-Graph Database (PGDb)" filesystem.  The rationale here is that a hierarchal tree-based filesystem can easily be represented as well but that a PGDb filesystem also allows for assigning new types of attributes to files, blocks, objects, users, etc. and thus allowing for granular security on users at the application level.  Users can be allowed/disallowed to see/access application/files/block/objects and only authorized applications are "mapped" to a particular user.

I think it's unlikely that we would move away from a hierarchical file
system.  It's really at the core of a lot of UNIX abstractions.  We
tend to focus on mandatory access control through privileges(7) and
rbac(7) mechanisms.  Individual users, or processes, can be restricted
from seeing quite a lot of other things occuring on the computer in
other accounts, etc, by removing privileges from their processes.
They can be prevented from making network connections, or seeing other
processes in /proc, etc.  We're always interested in new security and
sandboxing features, but would generally like them to build on and fit
in with the existing designs where possible.  The core team is happy
to help with design advice if someone wants to put together an illumos
project discussion (IPD) document that covers a new sandboxing
feature; see: https://github.com/illumos/ipd.

ZFS, our primary file system, has extensive support for extended
attributes.  It also has rich support for NFSv4 ACLs, which allow for
fine-grained permissions in the regular file system; see acl(7) for
more details.  There is also support for other more complex
attributes, such as marking things totally immutable; see fgetattr(3C)
and chmod(1) for more details.


3. I could see that when a user does a login, then a blank empty zones is set up at which time their configured files, directories are mapped in to their container zone and allowed applications are only used. The users cannot escape their zone and does not have access to the rest of the system unless privilege's are elevated.  I know that "zlogin" can do this from the GZ, but perhaps automatically and full console since graphic display will be needed.

You could achieve a lot of automatic provisioning for users on login
through some combination of NSS and PAM modules and
distribution-specific control software.  I don't think this would
really be a core illumos feature, at least to begin with, but there's
a lot of mechanism that could help you get there!

Graphics is obviously something of an uncharted challenge.  As I
mentioned in your OmniOS thread, our DRM/KMS software needs work to be
brought up to date, and there are probably new facilities that we
would then need to add to the core OS to provide a richer graphical
console experience.  It's also possible that you could, once DRM is
sorted out, drive a lot of that from distribution-specific software
like X11, or a port of DirectFB2, etc, without needing much or any
additional core OS support.


4. One need that may be a challenge to get done will be the need for a enable/disable consoles such that a local users could use a hot-key (API call) to switch between zone consoles which would include graphics, audio, etc.   This would be akin to running multiple VirtualBox OSs, or VMware Guests in which you can step through the guest graphic tabs in fullscreen mode, perhaps. I am seeking to replicate that idea in Illumos to step through guests (maybe in Bhyve or native zones) that are in their own configured zone which is the thought.

This is mostly the same as my comments on graphics above.  Some work
will be required specifically on improving the graphical/desktop
support we have, as part of a project like that.


I am not sure how these things might be approached and/or tackled in illumos but wanted to start investigating them one by one and build up at the project evolves.

I suspect most of what you want to do, you could get started by
prototyping on top of facilities that exist already!  I can't stress
enough that if you want the graphics stuff to work out, I would work
on that first, as I think it's the biggest risk/unknown in your plans
so far.


Well, I thought that I would ask these questions here since they are more kernel related than OS configuration related and hope that you also find them interesting although may have already been considered in the past well.

We generally try to keep the illumos developer list focused on
specific bits of in-progress development (questions about how to
proceed, code and design reviews), or about specific bugs or issues,
etc.  Generally we would do broad, exploratory ideation on the
illumos-discuss list.

Cheers.

--Apple-Mail-6C83CEA4-6171-44EB-BBD1-914962831500--