On Tue, May 09, 2023 at 01:59:33PM -0700, Palmer Dabbelt wrote: > On Tue, 09 May 2023 09:53:17 PDT (-0700), Conor Dooley wrote: > > On Wed, May 10, 2023 at 12:04:12AM +0800, Andy Chiu wrote: > > > > > +config RISCV_V_DISABLE > > > > > + bool "Disable userspace Vector by default" > > > > > + depends on RISCV_ISA_V > > > > > + default n > > > > > + help > > > > > + Say Y here if you want to disable default enablement state of Vector > > > > > + in u-mode. This way userspace has to make explicit prctl() call to > > > > > + enable Vector, or enable it via sysctl interface. > > > > > > > > If we are worried about breaking userspace, why is the default for this > > > > option not y? Or further, > > > > > > > > config RISCV_ISA_V_DEFAULT_ENABLE > > > > bool "Enable userspace Vector by default" > > > > depends on RISCV_ISA_V > > > > help > > > > Say Y here to allow use of Vector in userspace by default. > > > > Otherwise, userspace has to make an explicit prctl() call to > > > > enable Vector, or enable it via the sysctl interface. > > > > > > > > If you don't know what to do here, say N. > > > > > > > > > > Yes, expressing the option, where Y means "on", is more direct. But I > > > have a little concern if we make the default as "off". Yes, we create > > > this option in the worries of breaking userspace. But given that the > > > break case might be rare, is it worth making userspace Vector harder > > > to use by doing this? I assume in an ideal world that nothing would > > > break and programs could just use V without bothering with prctl(), or > > > sysctl. But on the other hand, to make a program robust enough, we > > > must check the status with the prctl() anyway. So I have no answer > > > here. > > > > FWIW my logic was that those who know what they are doing can turn it on > > & keep the pieces. I would expect distros and all that lark to be able to > > make an educated decision here. But those that do not know what they are > > doing should be given the "safe" option by default. > > CONFIG_RISCV_ISA_V is default y, so will be enabled for those upgrading > > their kernel. With your patch they would also get vector enabled by > > default. The chance of a breakage might be small, but it seems easy to > > avoid. I dunno... > > It's really more of a distro/user question than anything else, I'm not > really sure there's a right answer. I'd lean towards turning V on by > default, though: the defconfigs are meant for kernel hackers, so defaulting > to the option that's more likely to break something seems like the way to go > -- that way we see any possible breakages early and can go figure them out. To get my "ackchyually" out of the way, I meant the person doing `make olddefconfig` based on their distro's .config etc or using menuconfig rather than someone using the in-kernel defconfig. We can always set it to the potentially breaking mode explicitly in our defconfigs while leaving the defaults for the aforementioned situations as the "safe" option, no? > Depending on the risk tolerance of their users, distributions might want to > turn this off by default. I posted on sw-dev, which is generally the best > way to find the distro folks.
Attachment:
signature.asc
Description: PGP signature
