From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from tb-mx0.topicbox.com (localhost.local [127.0.0.1]) by tb-mx0.topicbox.com (Postfix) with ESMTP id B15191F6957D for ; Wed, 17 Jul 2024 16:22:10 -0400 (EDT) (envelope-from lonnie@outstep.com) Received: from tb-mx0.topicbox.com (localhost [127.0.0.1]) by tb-mx0.topicbox.com (Authentication Milter) with ESMTP id D108DB0EE76; Wed, 17 Jul 2024 16:22:10 -0400 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1721247730; b=h4oNCObzW/FntbPMRE4dobWBqL/FwgBixUcWyDida9dmAaReMz agqHB5XFpqzYdauJ0z/V2+poyJvQXg1BJ7VSblpjnsZBo/NiSOmNqCz9E5dS4REu vXW/5UyAIcxNPeOpaNL0qQtdG3XBcR5MclwjS7ybYmqy8hdSgr/TFZ3f+4MONpDF 5SxAYUbrncpirqJQ67oHtIxkQEDpGv8Dq8qoXLb0nMEeetgMF29aXFG5/ef98+6k hJCeDMLI2KsBff2OaAdN8RAV0QsnstxRZlKGwpwx/B59LXLB9WM3nIpz/tDoYCh2 7fWQm1V7d0bJoChUgUlUQV7ZW+nvg9E+pQFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=content-type:message-id:date:mime-version :subject:to:references:from:in-reply-to; s=arcseal; t= 1721247730; bh=z6knm0jD7bqemrYm/Y5MM+CTL64UBEegzy0ctkQuDYk=; b=h Y/O+nrzf+LctXUhX1lvNObbukOptwDZTZ3BbHk5V13nFIvtMafCJF8BpXJCNb2ob KtobgzsWgAvTNIkAx2VwjmB0tPUvp7yUzfrMWVvLRw4A/ITTDaWqUKeEd0s7iuAk ATBGdYAct6xyBwhkJ+F2y0c4iDNYzswDVvDmcVaXjnCj8+gB90rlTKXO/uV7Q+0o wV3sfUasbkAjmPzFNFRg1Lag5ToiDi8SyfQo9zFREx81NfnmSj+XtKbwCukNxHAx Z4zTeFZfT9ZxAmtcxGDt1cYO7oZLtkea5R97kr1ZxCAos8XbAxkBPGDrfNw22ae/ 7eyA63Dmi5kDxFbiDdrug== ARC-Authentication-Results: i=1; tb-mx0.topicbox.com; arc=none (no signatures found); bimi=skipped (Insufficient authentication, DKIM required); dkim=invalid (public key: DNS error: , unknown key sha256) header.d=outstep.com header.i=@outstep.com header.b=L5aZwU99 header.a=unknown-sha256 header.s=dkim; dmarc=pass policy.published-domain-policy=reject policy.applied-disposition=none policy.evaluated-disposition=none (p=reject,d=none,d.eval=none) policy.policy-from=p header.from=outstep.com; iprev=pass smtp.remote-ip=213.136.84.29 (mail.outstep.net); spf=pass smtp.mailfrom=lonnie@outstep.com smtp.helo=mail.outstep.net; x-aligned-from=pass (Address match); x-me-sender=none; x-ptr=pass smtp.helo=mail.outstep.net policy.ptr=mail.outstep.net; x-return-mx=pass header.domain=outstep.com policy.is_org=yes (MX Records found: mail.outstep.net); x-return-mx=pass smtp.domain=outstep.com policy.is_org=yes (MX Records found: mail.outstep.net); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 Authentication-Results: tb-mx0.topicbox.com; arc=none (no signatures found); bimi=skipped (Insufficient authentication, DKIM required); dkim=invalid (public key: DNS error: , unknown key sha256) header.d=outstep.com header.i=@outstep.com header.b=L5aZwU99 header.a=unknown-sha256 header.s=dkim; dmarc=pass policy.published-domain-policy=reject policy.applied-disposition=none policy.evaluated-disposition=none (p=reject,d=none,d.eval=none) policy.policy-from=p header.from=outstep.com; iprev=pass smtp.remote-ip=213.136.84.29 (mail.outstep.net); spf=pass smtp.mailfrom=lonnie@outstep.com smtp.helo=mail.outstep.net; x-aligned-from=pass (Address match); x-me-sender=none; x-ptr=pass smtp.helo=mail.outstep.net policy.ptr=mail.outstep.net; x-return-mx=pass header.domain=outstep.com policy.is_org=yes (MX Records found: mail.outstep.net); x-return-mx=pass smtp.domain=outstep.com policy.is_org=yes (MX Records found: mail.outstep.net); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgeeftddrgeejgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurheptgfkffggfg fuvfhfhfgjsegrtderredtvdejnecuhfhrohhmpefnohhnnhhivgcuvehumhgsvghrlhgr nhguuceolhhonhhnihgvsehouhhtshhtvghprdgtohhmqeenucggtffrrghtthgvrhhnpe elkeevvddtudffheegtdegteeffedvvdduhefffeefteeiiedvgfethefhudeugfenucff ohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedvudefrddufeeirdekgedrvdelne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddufedrudefiedr keegrddvledphhgvlhhopehmrghilhdrohhuthhsthgvphdrnhgvthdpmhgrihhlfhhroh hmpeeolhhonhhnihgvsehouhhtshhtvghprdgtohhmqedpnhgspghrtghpthhtohepuddp rhgtphhtthhopeeouggvvhgvlhhophgvrheslhhishhtshdrihhllhhumhhoshdrohhrgh eq X-ME-VSScore: 0 X-ME-VSCategory: clean Received-SPF: pass (outstep.com: 213.136.84.29 is authorized to use 'lonnie@outstep.com' in 'mfrom' identity (mechanism 'mx' matched)) receiver=tb-mx0.topicbox.com; identity=mailfrom; envelope-from="lonnie@outstep.com"; helo=mail.outstep.net; client-ip=213.136.84.29 Received: from mail.outstep.net (mail.outstep.net [213.136.84.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tb-mx0.topicbox.com (Postfix) with ESMTPS for ; Wed, 17 Jul 2024 16:22:03 -0400 (EDT) (envelope-from lonnie@outstep.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 87343234103E for ; Wed, 17 Jul 2024 22:21:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outstep.com; s=dkim; t=1721247720; h=from:subject:date:message-id:to:mime-version:content-type: content-language:in-reply-to:references:autocrypt; bh=z6knm0jD7bqemrYm/Y5MM+CTL64UBEegzy0ctkQuDYk=; b=L5aZwU99B4WSFvSdPuCwXd/OWf+jYLnIF0O0ROWQUKcHA6D5vFSVR782uaEgr09UWQ5rho hGA9ADKAgeIZXMwBYaa05lDT4RMB/IPPABP2sn2gJcKhwgBBcK9UPxTjrEXJ6R69Z3GjSe KmAbUQlvR+wjHsDBhGUwnr+RH9Tmfc8xowPBuleNCMYvnP56DsYDYlrbJsuT8cB5WucOrN ZJb3NWQcb3AlKsGXeDT2MXO0Fuuw6m2KcFQ/zi85pBghn3FwRkJIP37oaAhmjD3v1R95GT VXcKGuLTKHH1T2ehl4wi9jfGTPSlzFMAg1U63b5vlljrn2f6kf6S7VLrd8/U8A== Content-Type: multipart/alternative; boundary="------------NJh0972Phu7qMsAkiU8MOHjK" Message-ID: <936d4a1e-9fb3-4ee8-8ee6-870c33cd20de@outstep.com> Date: Wed, 17 Jul 2024 16:22:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [developer] A couple of kernel questions To: developer@lists.illumos.org References: <48-6697c700-1d7-71122080@11933559> Content-Language: en-US From: Lonnie Cumberland Autocrypt: addr=lonnie@outstep.com; keydata= xsDNBGZUkBcBDADf326hFXBZUOP9VKVMb569ZBxanDFn4/VSe88oit+OyvxtQoGWqEegTtpf 6zg1+9Dyx48+seZQvkbvZh/08CJaaNOZOP5uzwI70pWMpU+Uxvjed/Irl8Wp6pWixX+6qEm5 F7shGilvgxCbAPM8YH8Pp8M3nBy3IZGSS4vhlBlJHZ9VsvlZ69rvwJIcVv0igb1HEHkGFl3k O+odw9cScRVN7yLeqgAwXmhguZuOu0HN0UEgAgGszbPAPxckImOXI2c7gBbbl0P2aJwUPwKC CXb2SR4P/1lAsRJPFt37AyIjhPfLd9lKJVmxl+Jrd3xQ5TZUqAWOYNURJaKIQ7FmgPGtoXgi YZRg7rilc24FHbpjSYzAJwF6JNgn9ZJBOlY6Ra34SIFuB7m80dDYExRzYqQWjZZfLu3kQWv2 JDzxc0vnz1i8EkUYRlttz2RK+8bh0dbFQYRpyacAuUzqsthLOUMphuc2n994Ycjax3pXwt3H MvTjxZcB7tU5bBtnfV4XeyUAEQEAAc0mTG9ubmllIEN1bWJlcmxhbmQgPGxvbm5pZUBvdXRz dGVwLmNvbT7CwQcEEwEIADEWIQQulYU+Ak0zY3zlP1PNPEu2CUxXdQUCZlSQGAIbAwQLCQgH BRUICQoLBRYCAwEAAAoJEM08S7YJTFd1514MAJKgCilBtSfnDuqi6EsAv89vyLUC+UABqdIh ehwaImDTu65yniPARHsTQhXZI6QzfFTz3ptX7gQzZvAU0C1rVJWZaFbE4yHIEqerPPH5pTJA DL43GZU91is3BNE3hm2s3ArUHOEvFbWTzT9bQKjkHfPveByskzi0qlzrULZYG5kpbXx6sknW jFVdPkk0yv6N43ar9GjNKQqZTOJEe4U5VvHX3igMYjLB4dVmZFqvM9uMO+3pTQfnF4pzTtGd zX9ZIioAh/wQLF31P78ILvCUV4HOLVOGsxruZKuW/xEtA/UoLFJML5SJDrfbyNcu4Fly/5HP Yz42aNbnOBQkHOZKA7QaI0lfUgXgevAquRuJzvjjP8iKm+S+mpl7vIymsbkmG3E9tj5JAe9v xAyFFlQFi6ZVlw4PnXbiYUaJ30pa/AnrVe9nz5CpAxCX1q3ajRZApFeFYnuC7rx8LT662Pr1 fP5RRCbcUs5K8l2mJuifETtua+BydNQfn87JmmL0keAJGM7AzQRmVJAYAQwA9n99CBs/0XZk ZUzwm4CjPPqVQX7xLLqsvXZB15zsddCb21T+kxK7x2Bjg8QDg/4n/wOS8SytimPS35P1MKsm ysNi9lHkr3a3azfYGXZQ8jKfJbChD5dfyvu/rt4lK8k1EiNEUBzUFwTgP1WeD1v1+xUb5+JJ 6MjNFuMJMoq6vprEn0Wtv7LNDNWQj4/Xxa/kGVto9XwsrpcKSwyX7BmWEoqqzEO4PJgVSIF9 euL4GY15RCQD0Y+FN8kAXeO+Dd0WHgtaaWCpDP+RkgXtUCFx06Ozy1OrHRdIczsu+60Xcf+K DeoZsA2ZQTBwcSQN5ektrNeP5KqbYcl3stdW+grtucUs6AzFF3oqZbsrB6bNLyUUjEuYvrMm SFVi1rfOiGc6IExl6QDT0GCf5KWv0iGbls7lNfYHVUcdbUM07LDxLhm3MkcAnLFpAHg1s+Pz QP858J+fpnZLvMQT9AQ/bfA6c3kw6VRFqbsAe7ZzI4C73N+nzsP9ow5ovIbvECI+xkzZABEB AAHCwPYEGAEIACAWIQQulYU+Ak0zY3zlP1PNPEu2CUxXdQUCZlSQGQIbDAAKCRDNPEu2CUxX dTdmDADYJA7nWcJrr/3Oz+KvND+5Qd7jyOsTnvmcmFmpqWkydxbn75DciH1le9qf3F+WBT2x CQtsFGu0E7mb4bQv2i1ugyoWOJPlVAbRvwUoyFYbxHLnlSPPq6KBLcoRDNUe26oINuH6CK30 ZcXF0SDY26ydP7r6bC0cAzNTz6fkQsEd57wy/nSz9bt0EZnapYZ9l/W5fTSqyMcYDF92u18J IAn7On392bs3yTSwAeahPT+dhk3qOecbFysJRm61dw0vNCKVvm82tJKvzRPYEuFMDQEvpXb3 OqxCCRk3v0iUxwcXZxXPZAfos7ZrM2Y9ElSHfrssbvbeqDIOrGa0d2GlfHZMlz+mnH84Np5K 19Q/WetiOD7SKvmR54d7jZvsBt8VyDlQhMYqbNPyOnkvtQUhVWshrGGwKrB5a89dUYZMmAQd fL+vxMw4kBmeZmZ64Iy9ROZmDqVYD8278qC+yJC2S+uEdW9VjeW4WsUljfH2P3O8QagZsvGv WujEwGqqyfUF7eo= In-Reply-To: X-Last-TLS-Session-Version: TLSv1.3 Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 41749762-447a-11ef-b7bb-747d068c7b06 This is a multi-part message in MIME format. --------------NJh0972Phu7qMsAkiU8MOHjK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > 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. --------------NJh0972Phu7qMsAkiU8MOHjK Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 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.

--------------NJh0972Phu7qMsAkiU8MOHjK--